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PREFACE 


This  report,  prepared  by  the  U.S.  Department  of  TransportationAiransportation  Systems 
Center  (DOT/TSC),  describes  the  analysis  of  the  current  Software  Product  Data  (SPD)  envi¬ 
ronment  that  was  undertaken  as  part  of  the  U.S.  Air  Force  Computer-aided  Acquisition  and 
Logistic  Support  (CADS)  Program.  This  investigation  was  coordinated  by  the  Air  Force 
CALS  Management  Integration  Office  (MIO)  at  HQ  AFSC/ENXC. 

The  report  describes  the  Air  Force  organization  and  functions  employed  in  the  acquisition, 
use,  and  management  of  SPD.  The  flow  of  data  among  the  Air  Force  and  contractors  during 
the  design,  development,  and  post-production  phases  has  been  defined.  In  addition,  the 
report  describes  the  major  findings  identified  during  the  current  environment  analysis. 

The  work  was  performed  by  the  Information  Integration  Division  at  TSC.  TSC  has  drawn 
upon  the  knowledge  and  experience  of  a  number  of  consultants,  and  would  like  particularly 
to  recognize  the  efforts  of  staff  members  from  EG&G/DYNATREND  Inc.  and  UNISYS  Cor¬ 
poration.  In  addition,  TSC  would  like  to  extend  thanks  and  gratitude  to  the  members  of  the 
.Air  Force  and  defense  contractors  who  contributed  to  the  development  of  this  report. 

The  SPD  Current  Environment  Report  identifies  a  baseline  for  the  development  of  an  auto¬ 
mation  plan  (seven  to  ten  years)  to  digitally  receive,  manage,  store,  use,  and  distribute  SPD. 
Axiy  comments  or  inputs  are  encouraged  so  that  this  report  will  be  current  and  integral  to  the 
success  of  this  program. 
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COAL  OF  THE  AIR  FORCE  SOFTWARE  PRODUCT  DATA  (SPD)  PROGRAM 

The  SPD  modular  planning  program  is  part  of  the  Air  Force  Computer-aided  Acquisition 
and  Logistic  Support  (CALS)  Program.  SPD  is  defined  as  the  technical  data,  source  code,  and 
tools  needed  to  design,  test,  and  implement  Mission  Critical  Computer  Resources  (MCCR) 
software  during  the  acquisition  phase  of  the  weapon  system  life  cycle,  and  to  support  and 
modify  MCCR  software  during  the  operational  phase.  The  requirement  to  address  SPD  re¬ 
sulted  from  the  analysis  performed  for  the  Product  Definition  Data  (PDD)  program  within 
CALS.  During  this  effort,  several  interviews  with  major  weapon  system  program  offices  iden¬ 
tified  the  importance  of  SPD  as  well  as  PDD,  given  the  increased  proportion  of  software  with¬ 
in  a  weapon  system. 

The  Air  Force  CALS  Program  is  developing  automation  plans  that  define  the  infrastructure, 
functional  requirements,  technologies,  and  implementation  strategy  to  receive,  use,  and  dis¬ 
seminate  digital  technical  data.  The  program  uses  a  phased  Modular  Planning  Process  (MPP) 
w  hich:  1)  examines  the  current  environment,  2)  studies  the  opportunities  and  3)  plans  the  fu¬ 
ture  direction.  The  areas  of  technical  data  currently  being  addressed  in  CALS  are:  SPD,  Tech¬ 
nical  Orders  (TOs),  Product  Definition  Data  (PDD),  and  Logistics  Support  Analysis  (LSA). 

The  goal  of  the  SPD  modular  planning  program  is  to  achieve  the  benefits  available  from  auto¬ 
mating  the  flow  of  software,  software  documentation,  and  tools  from  industry  to  the  Air 
Force.  By  digitizing  the  receipt,  distribution,  storage,  and  configuration  management  of  SPD, 
the  Air  Force  will  have  a  stronger  capability  to  manage  SPD  not  only  during  acquisition,  but 
throughout  system  deployment.  Improved  management  and  control  of  SPD  provides  the  op¬ 
portunity  to  provide  the  right  data,  to  the  right  place  at  the  right  time.  This  capability  will 
increase  the  potential  to  develop  and  field  high  quality  software  modifications  faster.  In  turn, 
this  will  improve  mission  readiness  and  productivity.  As  weapon  systems  grow  more  depen¬ 
dent  on  software  (a  key  element  in  the  force  multiplier  equation),  this  effort  will  identify  ways 
to  provide  SPD  to  the  weapon  systems  so  that  SPD  can  continue  to  adapt  to  new  or  changed 
mission  requirements. 

In  summary,  the  SPD  program  will  develop  a  system  concept  plan  for  the  digital  acquisition, 
distribution,  storage,  use,  and  configuration  management  of  SPD. 

THE  PROBLEM  OF  SPD  IN  THE  AIR  FORCE  TODAY 

Increasingly,  software  is  playing  a  critical  role  in  weapon  system  operations.  To  that  end,  soft¬ 
ware  and  software-re'ated  deliverables  must  be  acquired,  managed,  and  utilized  efficiently  to 
support  the  broader  role  of  software  within  a  weapon  system.  As  newer,  more  software-in- 
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tensive  systems  are  produced,  insufficient  documentation  and  design  information  is,  and  will 
be,  an  ever-increasing  problem.  To  resolve  this,  SPD  must  be  addressed  as  an  integral  com¬ 
ponent  of  a  weapon  system’s  technical  data. 

Today,  the  vast  majority  of  Air  Force  software  documentation  at  Air  Logistics  Center  (ALC) 
libraries  is  paper-based,  which  makes  it  difficult  to  use  in  software  maintenance  and  modifi¬ 
cations.  This  is  attributed  to  the  enormous  effort  that  is  necessary  to  maintain  and  update 
design  information  in  a  paper-based  repository.  Frequently,  documentation  cannot  be  ac¬ 
quired,  cannot  be  found,  or  contains  insufficient  information  to  expeditiously  complete  soft¬ 
ware  maintenance  and  modifications.  In  addition,  the  ALCs  and  involved  Using  Commands 
usually  do  not  have  automated  support  tools,  which  are  becoming  a  prerequisite  to  effective 
Post-Deployment  Software  Support  (PDSS).  From  a  cost  perspective,  PDSS  represents  80% 
of  the  software  life  cycle  costs.  Without  sufficient  quality  documentation  and  automated  sup¬ 
port  tools,  system  modifications  become  expensive.  This  affects  the  potential  system  life  of 
weapon  systems,  reduces  responsiveness  to  mission-critical  software  change  requirements, 
and  increases  labor  costs  for  maintenance  and  modifications. 

PURPOSE  OF  THIS  REPORT 

The  CALS  SPD  Current  Environment  Report  documents  the  current  functions,  organizations, 
and  findings  related  to  the  acquisition  and  operational  processes  for  MCCR  in  weapon  sys¬ 
tems  and  major  items.  This  report  is  part  of  Phase  1  of  the  SPD  module  and  will  be  followed 
by  additional  reports.  Together,  these  products  will  provide  a  baseline  for  developing  and 
implementing  an  SPD  System  Concept  Plan. 

Major  sections  of  this  report  are  summarized  as  follows: 

•  Organizational  Assessment  -  Describes  the  Air  Force  organizations  and 
their  primary  functions  relating  to  SPD  throughout  the  life  cycle. 

•  IDEFo  Diagrams  -  Depict  the  functional  description  of  how  the  Air  Force 
acquires,  uses,  and  manages  SPD  through  IDEFo  (ICOM  Definitions). 
The  diagrams  also  depict  the  Input,  Controls,  Output,  and  Mechanisms 
(ICOMs)  and  the  interrelationships  among  the  functions. 

•  Findings  -  Present  current  SPD  environment  findings  that  were  identified 
through  an  extensive  literature  search  and  through  interviews  with  various 
program  offices,  support  organizations,  Using  Commands,  and  outside 
agencies. 

CURRENT  ENVIRONMENT  SUMMARY 

Examination  of  the  client  SPD  environment  revealed  the  following: 

•  Major  Organizations  -  The  organizational  assessment  established  that  the 
ALC  Materiel  Management  (MM)  and  Maintenance  (MA)  Directorates 
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are  the  predominant  users  of  SPD  for  supporting  post-Production  support 
applications.  The  Air  Force  Systems  Command  (AFSC)  Product  Divisions/ 
System  Program  Offices  (SPOs)  are  responsible  for  SPD  acquisition  and 
reviews;  their  contractors  create  most  SPD.  Finally,  the  Using  Commands 
are  beginning  to  require  SPD  to  support  base-level  software  maintenance 
and  modifications. 

Major  Applications  -  SPD  facilitates  several  pre  and  post-production  sup¬ 
port  applications: 

o  Software  Development  -  Throughout  the  development  cycle  described  in 
DOD-STD-2167A,  the  series  of  reviews  provides  the  Air  Force  with 
the  opportunity  to  verify  and  validate  the  requirements,  solution,  ap¬ 
proach,  design,  and  final  as-built  product.  To  convey  technical  com¬ 
pliance  within  the  design  review,  products  (such  as  those  available  un¬ 
der  DOD-STD-2167A)  are  generated.  Those  products  are  examined 
during  the  development  phase  and  during  the  physical  and  functional 
configuration  audits. 

o  Software  Maintenance  -  The  ALCs  and  Using  Commands  perform  a  va¬ 
riety  of  maintenance  tasks,  such  as  fixing  or  compensating  design  flaws 
or  coding  errors,  maximizing  available  memory  space,  and  improving 
the  software’s  efficiency.  Use  of  SPD  is  critical  to  the  efficient  perform¬ 
ance  of  software  maintenance. 

o  Software  Modifications  -  Software  modifications  made  by  the  ALCs  and 
Using  Commands  either  enhance  the  capability  of  the  software  or  in¬ 
corporate  a  change  in  mission.  Software  modification  tasks  mirror 
those  of  the  software  development  cycle.  Use  of  a  current  SPD  baseline 
is  the  major  starting  point  for  software  modifications. 

o  Reverse  Engineering  of  Software  -  Some  ALCs  reverse  engineer  software 
code  to  develop  documentation  for  undocumented  code.  This  usually 
takes  place  when  the  system  life  is  expected  to  be  long  and  the  difficul¬ 
ties  of  supporting  the  code  outweigh  the  costs  of  reverse  engineering  the 
code.  Reverse  engineering  makes  use  of  available  SPD  to  begin  the  re¬ 
construction  process. 

o  Documentation  Updates  -  As  software  is  modified  and  maintained,  the 
software  documentation  should  be  updated  at  the  same  time  so  that  a 
current  baseline  is  available  for  future  maintenance  and  modifications. 
In  addition,  this  documentation  will  support  the  development  of  the 
TOs  that  are  needed  to  implement  changes  in  the  weapon  system. 


•  Findings  -  Specific  findings  are  summarized  below: 

o  Software  configuration  management  is  impeded  in  the  Air  Force  today 
due  to  a  variety  of  factors,  (e.g.,  lack  of  documentation,  fragmentation 
of  support  responsibility,  and  lack  of  automated  configuration  manage¬ 
ment  systems)  which  in  turn  hinder  PDSS. 

o  Lack  of  adequate  software  support  documentation  is  currently  a  major 
problem  since  it  affects  the  Air  Force’s  capability  to  maintain  and 
modify  existing  software  inventories. 

o  There  is  a  lack  of  CALS  standards  for  the  digital  receipt,  management, 
and  use  of  SPD. 

o  Logistics  resources  to  support  software  need  to  be  identified  during  the 
acquisition  phase,  either  through  DOD-STD-2167  A  or  through  appli¬ 
cation  of  the  LSA  process  to  software. 

o  Changes  to  software  within  AFLC  most  often  require  a  TCTO  to  imple¬ 
ment  the  software  change. 

o  The  role  of  the  Air  Force  Logistics  Command  (AFLC)  and  Using  Com¬ 
mands  is  changing  in  relation  to  software  acquisition  and  support. 
Shared  software  maintenance  responsibilities  among  selected  LTsing 
commands  are  emerging. 

o  The  ALCs  sometimes  act  as  the  Independent  Verification  and  Valida¬ 
tion  (IV&V)  agent  (either  performing  the  IV&V  directly  or  issuing  a 
contract  to  have  it  done).  This  is  an  effective  means  to  prepare  the  ALC 
for  its  PDSS  responsibility  and  can  lead  to  supportability  improvements 
in  the  software  design.  However,  this  practice  is  not  performed  often 
enough. 

o  Software  that  was  developed  under  DOD-STD-2167A  still  represents 
a  small  percentage  of  AFLC  software  inventories;  this  is  due  to  a  large 
inventory  that  existed  prior  to  this  standard  and  to  short-term  cost  in¬ 
centives  that  avoid  use  of  the  standard  on  selected  modification  pro¬ 
grams. 

o  The  use  of  Computer-Aided  Software  Engineering  (CASE)  tools  is  cur¬ 
rently  minimal  in  Air  Force  software  maintenance. 

o  Testing  issues  need  to  be  identified  early  in  the  software  life  cycle. 

o  Retention  and  training  of  software  personnel  in  the  Air  Force  will  be 
critical  for  achieving  mission  readiness,  productivity,  and  maximizing 
competition  in  PDSS  contracting. 
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SUMMARY 


This  report  identifies  the  current  Air  Force  process  for  developing  and  fielding  embedded 
computer  software  systems.  It  also  identifies  the  organizations  mat  are  responsible  for  devel¬ 
oping  SPD,  or  that  depend  on  SPD  to  adapt  software  to  changing  mission  requirements.  The 
report  findings  begin  to  identify  potential  CALS  opportunities  and  will  provide  the  building 
blocks  for  developing  the  CALS  SPD  System  Concept  Plan.  The  SPD  effort  will  identify  how 
quality  SPD  data  can  be  provided  at  the  right  place  and  at  the  right  time. 
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SECTION  1:  INTRODUCTION 


1.1  USAF  CALS  BACKGROUND 

In  conjunction  with  the  Computer-aided  Acquisition  and  Logistic  Support  (CALS)  program 
used  throughout  the  Department  of  Defense  (DoD),  the  Air  Force  CALS  program  was  estab¬ 
lished  to  improve  weapon  system  reliability  and  maintainability,  and  to  reduce  the  cost  of 
acquisition  and  support.  A  major  objective  of  CALS  is  to  improve  the  flow  of  technical  infor¬ 
mation  by  introducing  automated  techniques  to  improve  the  delivery  and  handling  of  large 
quantities  of  digitized  technical  data.  The  areas  of  technical  data  currently  being  addressed 
by  the  Air  Force  CALS  Program  are:  Software  Product  Data  (SPD),  Technical  Orders  (TOs), 
Product  Definition  Data  (PDD),  and  Logistics  Support  Analysis  (LSA).  By  automating  the 
flow  of  information,  CALS  will  significantly  reduce  the  amount  of  paper  and  labor  necessary 
to  receive,  store,  use,  and  disseminate  these  technical  data. 

In  October  1985,  an  Air  Force  Program  Management  Directive  (PMD)  created  a  CALS  Man¬ 
agement  Integration  Office  (MIO)  at  HQ  Air  Force  Systems  Command  (AFSC)  to  coordinate 
the  CALS  program.  The  Air  Force  CALS  MIO  is  responsible  for  planning,  developing,  and 
implementing  the  CALS  initiatives.  The  U.S.  Department  of  Transportation,  Transportation 
Systems  Center  (DOT/TSC),  is  providing  systems  engineering  and  strategic  planning  support 
to  the  CALS  MIO. 

1.2  SOFTWARE  PRODUCT  DATA  DEFINITION 

SPD  represents  the  set  of  technical  information,  such  as  logic  diagrams,  block  diagrams, 
source  code,  specifications,  tests,  tools  and  other  data,  which  is  needed  to  both  acquire  and 
support  the  design,  test  and  implementation  of  Mission  Critical  Computer  Resources 
(MCCR)  software.  Specific  examples  of  SPD  information  types  are  shown  in  FIGURE  1-1. 
A  complete  list  of  SPD-related  Data  Item  Descriptions  (DIDs)  associated  with  DOD- 
STD-2167A  is  presented  in  TABLE  1-1. 

Software  implementation  is  not  limited  to  weapon  systems  and  can  also  apply  to  ground 
equipment,  communication  devices  (both  ground  and  platform  based),  radars,  and  end  items 
such  as  smart  munitions  and  missiles.  Thus,  SPD  is  found  not  only  on  major  weapon  systems, 
but  also  on  major  end  items. 

1.3  OBJECTIVE 

The  objective  of  the  CALS  SPD  modular  planning  program  is  to  develop  a  system  concept 
plan  for  the  digital  acquisition,  distribution,  storage,  use,  and  configuration  management  of 
SPD.  The  system  concept  plan  will  define  a  strategy  for  implementing  CALS  objectives  in  the 
arena  of  SPD  in  a  manner  that  it  consistent  with  long-term  Air  Force  CALS  goals.  To  identify 
these  requirements,  the  functions  that  are  required  to  acquire  and  support  software  will  be 
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identified,  defined,  and  analyzed.  The  approach  will  include  defining  how  the  software  com¬ 
ponent  of  a  weapon  system  is  supported,  identifying  the  shortcomings,  and  anticipating  the 
functional,  organizational,  and  technical  support  requirements  for  the  weapon  system  soft¬ 
ware  of  tomorrow. 


FIGURE  1-1.  EXAMPLES  OF  SPD  BY  CATEGORIES 

By  digitizing  the  acquisition,  distribution,  storage,  use,  and  configuration  management  of 
SPD,  the  Air  Force  will  realize  benefits  by  more  accurately  and  rapidly  maintaining  and  modi¬ 
fying  software.  This  will  translate  into  improvements  in  mission  readiness  and  productivity. 

1.4  SOFTWARE  PRODUCT  DATA  SCOPE 

The  definition  of  a  weapon  system  as  a  product  includes  both  product  definition  and  software 
product  data  as  illustrated  in  FIGURE  1-2.  PDD  consists  of  the  technical  information  that 
describes  the  hardware  of  a  weapon  system  while  software  product  data  consists  of  the  techni¬ 
cal  information  that  describes  the  software.  In  general,  PDD  includes  engineering  drawings, 
lists,  analysis,  and  design  data  related  to  hardware  aspects  of  the  system. 
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TABLE  1-1.  DoD-STD-2 167 A  DATA  ITEMS 


TITLE 

NUMBER 

System/Segment  Specification  (SSS) 

DI-CMAN-80008A 

System/Segment  Design  Document  (SSDD) 

DI-CM  AN-80534 

Software  Development  Plan  (SDP) 

DI-MCCR-80030A 

Software  Requirements  Specification  (SRS) 

DI-MCCR-80025A 

interface  Requirements  Specification  (IRS) 

DI-MCCR-80026A 

Software  Design  Document  (SDD) 

DI-MCCR-8001 2A 

Interface  Design  Document  (IDD) 

DI-MCCR-80026A 

Software  Product  Specification  (SPS) 

DI-MCCR-80028A 

Version  Description  Documen*  (VDD) 

DI-MCCR-8001 3A 

Software  Test  Plan  (STP) 

DI-MCCR-8001 4A 

Software  Test  Description  (STD) 

DI-MCCR-8001 5A 

Software  Test  Report  (STR) 

DI-MCCR-8001 7A 

Computer  System  Operator’s  Manual  (CSOM) 

DI-MCCR-8001 8A 

Software  User's  Manual  (SUM) 

DI-MCCR-8001  1A 

Software  Programmer's  Manual  (SPM) 

DI-MCCR-80021 A 

Firmware  Support  Manual  (FSM) 

DI-MCCR-  80022A 

Computer  Resources  Integrated 

Support  Document  (CRISD) 

DI-MCCR-80024A 

FIGURE  1-2.  WEAPON  SYSTEM  PRODUCT  DEFINITION 

DoD  computer  resources  were  divided  into  two  categories  by  the  Warner  amendment  to  the 
(  ongr essional  Brooks  Bill  in  1982:  Mission  Critical  Computer  Resources  (MCCR)  and  Infor- 
mation  System  Resources  (ISR).  According  to  the  AFR  700-4  definition  there  are  five  appli¬ 
cations  for  MCCR,  as  shown  in  FIGURE  1-3. 

1-3 


MCCR 

INTELLIGENCE  CRYPTOLOGICAL  EMBEDDED 

COMMAND  & 

RESOURCES 

COMPUTER 

CONTROL 

CRITICAL  TO 

RESOURCES 

MILITARY  & 

INTELLIGENCE 

MISSIONS 

References:  DoDD  5000.29,  AFR  700-4,  Vol.2;  Sec  2315  of  Title  10,  OSC 

FIGURE  1-3.  COMPONENTS  OF  MCCR 


Weapon  systems  today  utilize  software-driven  electronic  and  electro-mechanical  equipment 
that  is  largely  dependant  on  MCCR  software.  According  to  AFLCR  800-21  (Management 
and  Support  Procedures  for  Computer  Resources  Used  in  Defense  Systems)  embedded  com¬ 
puter  resources  can  be  broken  down  into  five  application  areas: 

•  Digital  avionics  system  or  Operational  Flight  Program  (OFP), 

•  Electronic  Warfare  (EW)  software, 

•  Aircrew  Training  Devices  (ATD)  software, 

•  Automatic  Test  Equipment  (ATE)  software,  and 

•  Communications-Electronics  (C-E)  software. 

The  scope  of  the  CALS  SPD  program,  and  of  this  report,  is  limited  to  the  five  types  of  MCCR 
listed  above  (OFP,  EW,  ATD,  ATE,  and  C-E).  These  embedded  software  sub-types  are  cen¬ 
tral  to  the  functioning  of  a  weapon  system  and  collectively  represent  the  largest  of  the  five 
MCCR  categories.  Subsequent  work  could  apply  the  results  of  this  study  to  the  other  MCCR 
categories  discussed  above. 

Proposed  changes  to  current  regulations  will  redefine  and  broaden  the  scope  of  MCCR,  and 
delete  the  use  of  the  term  Embedded  Computer  Resources  (ECR).  This  would  elevate  the 
five  sub-categories  currently  defined  under  ECR  (shown  in  the  above  bullets),  and  increase 
the  total  number  of  categories  under  MCCR  to  nine  (the  other  four  categories  are  shown  in 
FIGURE  1-3).  For  this  report  however,  MCCR  will  still  be  used  to  describe  the  five  catego¬ 
ries  of  computer  resources  above  (OFP,  EW,  ATE,  ATD,  and  C-E).  This  was  done  to  use 
clear,  understandable  terms,  and  to  reflect  in  the  report  the  current  state  and  evolving  nature 
of  software  in  the  mission  critical  environment. 

The  scope  of  the  CALS  SPD  program  is  a  representative  subset  of  Air  Force  SPD. 
FIGURE  1-4  illustrates  that  the  five  types  of  MCCR  span  both  the  prime  mission  and  support 
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systems  of  a  weapon  system.  It  also  shows  that  Computer  Software  Configuration  Items 
(CSCIs)  are  the  broadest  or  highest  level  of  software  configuration  item.  CSCIs  are  computer 
programs  that  meet  an  end  usage  function;  according  to  DOD-STD-2167A,  each  CSCI  is 
subject  to  full  configuration  management.  CSCIs,  in  turn,  are  broken  down  into  Computer 
Software  Components  (CSCs)  and  then  into  Computer  Software  Units  (CSUs). 


FIGURE  1-4.  MCCR  WITHIN  A  WEAPON  SYSTEM 


1.5  CRITICALITY  OF  SPD 


Increasingly,  software  is  playing  a  more  mission-critical  role  in  weapon  system  operations. 
This  results  from  the  evolution  of  the  integration  of  computers  and  software  into  weapon  sys¬ 
tems  hardware.  To  that  end,  software  and  software-related  deliverables  must  be  acquired, 
managed,  and  utilized  efficiently  to  support  the  broader  and  more  time-critical  role  of  soft- 
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ware  within  a  weapon  system.  As  newer,  software-intensive  systems  are  produced,  any  un¬ 
supported,  undocumented  software  will  represent  an  ever  increasing  problem. 

MCCR  is  an  integral  component  of  the  weapon  system  and  must  therefore  be  included  within 
the  technical  data  for  each  weapon  system.  As  weapon  systems  grow  more  complex,  software 
is  being  applied  to  the  hardware  to  perform  the  sensing,  processing,  complex  calculations, 
and  control  functions  that  can  no  longer  be  performed  manually  to  support  mission  require¬ 
ments.  The  software  acts  as  the  central  nervous  system  to  the  entire  weapon  system,  and  must 
therefore  be  the  major  focus  of  how  support  is  managed  and  provided  to  the  weapon  system. 

Fundamental  breakdowns  in  software  management  can  be  attributed  primarily  to  the  intrica¬ 
cies  inherent  in  the  software.  Minor  development  deficiencies  (poor  documentation,  insuffi¬ 
cient  testing,  inadequate  review,  or  lack  of  configuration  control)  can  turn  into  major  opera¬ 
tional  deficiencies  once  the  weapon  system  is  fielded.  A  major  SPD  problem  facing  the  Air 
Force  is  that  once  a  system  is  fielded,  it  may  be  too  costly,  or  logistically  impossible  to  retro- 
develop  SPD  that  was  not  acquired  during  the  acquisition  phase;  this  in  turn  hinders  mission 
capability  and  staff  productivity. 

Since  post-deployment  software  support  functions  have  significant  similarities  to  software 
development  tasks,  software  support  requires  an  up-to-date  baseline  of  software  documen¬ 
tation,  tools,  and  code  (i.e.,  SPD)  to  perform  software  maintenance  and  modification  tasks 
quickly  and  effectively.  Approximately  66%  of  software  support  activities  require  new  devel¬ 
opment  of  software,  an  indication  that  software  support  does  not  fall  under  the  classic  “prob¬ 
lem  correction”  definition  of  maintenance. 

During  the  support  phase  of  the  software  life  cycle,  software  modifications  usually  result  from 
change  requests  by  the  user,  or  a  change  in  the  mission  requirement.  Currently,  software 
changes  are  a  labor-intensive  activity,  prompting  major  releases  on  an  eighteen  month  re¬ 
lease  cycle  (except  safety-of-flight  modifications).  Gn  average,  modifications  to  embedded 
computer  software  take  up  to  four  times  longer  to  implement  than  modifications  made  during 
the  initial  development.  Current  studies  have  estimated  that  60%  of  the  time  required  to 
implement  a  modification  is  devoted  to  retrieving  and  updating  documentation.  Therefore, 
successful  software  support  (modifications,  enhancements,  fixes,  testing,  etc.)  of  weapon  sys¬ 
tem  software  is  significantly  dependant  on  SPD. 

1.6  METHODOLOGY 

To  undertake  the  strategic  planning  associated  with  the  CALS  initiatives,  TSC  has  developed 
and  implemented  the  Modular  Planning  Process  (MPP),  an  information  engineering  ap¬ 
proach  that  is  designed  to: 

•  Focus  on  technical  plans  that  will  not  be  outdated  before  implementation. 

•  Incorporate  existing/on-going  Air  Force  systems. 
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•  Meet  the  information  distribution  requirements  of  the  Air  Force  user  com¬ 
munity. 

•  Interface  with  a  variety  of  organizations  responsible  for  weapon  systems  ac¬ 
quisition  and  logistic  support. 

The  MPP  is  divided  into  three  phases:  1)  an  examination  of  the  existing  environment,  2)  a 
study  of  opportunities,  and  3)  a  plan  of  future  direction  (see  FIGURE  1-5) .  Using  this 
framework.  The  Air  Force  Technical  Order  Management  System  (AFT O MS)  Automation  Flan 
was  developed  and  a  concept  has  been  approved  for  managing  technical  orders.  In  addition,  a 
Product  Definition  Data  System  Concept  Plan  was  developed  using  the  MPP. 

This  report  presents  the  results  of  an  examination  of  the  existing  SPD  environment,  under¬ 
taken  as  the  first  phase  in  the  MPP,  and  as  an  initial  step  in  developing  a  SPD  System  Concept 
Plan.  It  will  assist  the  CALS  effort  in  planning  for  SPD  automation  over  the  next  ten  years  by 
accommodating  present  Air  Force  acquisition  and  logistics  requirements,  meeting  future  Air 
Force  requirement,  and  providing  flexibility  to  take  advantage  of  future  advances  in  technol¬ 
ogy. 

This  report  was  prepared  from  site  visits,  an  analysis  of  the  current  regulations  for  directing 
and  guiding  the  acquisition,  receipt,  management,  and  use  of  SPD,  background  documenta¬ 
tion,  and  telephone  contacts.  Regulations  and  background  documentation  are  cited  in  Ap¬ 
pendix  C  of  this  document.  Air  Force  organizational  contacts  to  validate  the  findings  of  the 
report  are  listed  in  Appendix  D. 

Regulations  referred  to  in  developing  this  report  include  those  governing  MCCR  software, 
are  contained  in  the  800  series  regulations.  Two  important  regulations  for  this  report  include 
AFR  800-14,  Life  Cycle  Management  of  Computer  Resource  in  Systems,  and  AFLCR  800-21, 
Management  and  Support  Procedures  for  Computer  Resources  Used  in  Defense  Systems. 

1.7  RELATED  STUDIES  AND  INITIATIVES 

The  DoD  and  the  Air  Force  have  already  initiated  and  conducted  several  studies  whose  objec¬ 
tives  were  to  understand  the  full  context  of  managing  software  from  a  weapons  systems  per¬ 
spective  and  identify  the  critical  elements  attributable  to  the  labor-intensive  effort  of  main¬ 
taining  weapon  system  software. 

As  early  as  1980,  studies  tried  to  determine  why  software  so  often  becomes  the  limiting  factor 
in  mission  support.  In  1980,  TRW  developed  an  eight  volume  study  for  ASD  that  reviewed 
each  category  of  embedded  computer  resources  from  a  maintenance  standpoint.  Ayear  later, 
the  RAND  Corporation  developed  a  study  to  review  Post-Deployment  Software  Support 
(PDSS)  issues.  The  following  year,  the  Defense  Science  Board  formulated  a  task  force  on 
embedded  computer  resources  to  “review,  evaluate  and  make  recommendations  concerning 
the  acquisition,  management  and  utilization  of  digital  computers  and  technology  to  support 
the  military  mission  of  the  Department  of  Defense”.  More  detailed  information  on  these  and 
other  studies  is  provided  in  Appendix  A 
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PHASE  1 

EXAMINE  THE  ENVIRONMENT 


PHASE  2 

STUDY  THE  OPPORTUNITIES 


PHASE  3 

PLAN  THE  DIRECTION 


Initiate  the  Process 

Perform  Initial  Assessment 

•  Create  Pre*irr,inary  Dr~,  ipticr. 
oi  Environment 

•  Identify  Organizational 
Expectations 

•  Establish  Priorities 

Develop  Specific  Procedures 

•  Establish  Management  Plan 

•  Identify  Advisory  Group 

•  Prepare  Project  Plans 

Conduct  Structured  Analysis 

Describe  Current  Environment 

•  Create  Functional  Model 

•  Identify  Major  Data  Elements 

•  Describe  the  Organizational 
Infrastructure 

•  Identify  Major  Information 
Flow  Parameters 

Assess  Transitional  Projects 

•  Identify  Objectives 

•  Describe  Functions  and  Data 

•  Identify  Technologies 

•  Identify  Infrastructure  Affected 


Assess  Technology 

Identify  Existing  Technologies 

•  Tie  .-'  ?"  Cm  rent  En  vfronment 

•  Review  Ongoing  Projects 

•  Identify  Existing  Technologies 

Research  Future  Technology 
Opportunities 

•  Select  Technology  Areas 

•  Consult  with  Technology  Experts 

•  Examine  Similar  Applications 

•  Review  Development  Trends 

Establish  Technology  Alternatives 

•  Quantify  Directions 

•  Specification  of 
Implementation  Issues 

•  Examine  Benefits  and  Costs 

Project  Future  Requirements 

Forecast  Requirements 

•  Review  Applicable  Scenarios 

•  Conduct  Discussions 
with  MAJCOMs 

•  Forecast  Process  Changes 

•  Assess  Infrastructure 
Constraints 

Examine  Feasible  Alternatives 

•  Determine  Feasibility  Issues 

•  Review  Industry  Trends 

Define  Future  State 

Describe  Future  Environment 

•  Define  the  Impact  of  Technology 
on  Current  State 

•  Define  Projected  Organizational 
Responsibilities 

•  Define  Relevant  Interface 
Requirements 

Create  Functional  Model 

•  Develop  a  Description  of 
Future  State 

•  Identify  Projected  Major 
Information  Flow  Parameters 


Formulate  Alternatives 

Assess  Critical  Issues 

•  Examine  Objectives 

•  Identify  Technologies 

•  Review  Organizational  Issues 

Propose  Initial  Alternatives 

•  Select  Future  Requirements 

•  Identify  Technologies 

•  Structure  Proposals 

Review  and  Modify  Alternatives 

•  Review  Criteria 

•  Identify  Relationships  with 
Transitional  Projects 

•  Define  Policies  and  Organizations 
Involved 

Develop  Consensus 

Review  Progress  with  Advisory  Group 

•  Identify  Discussion  Topics  and 
Priorities 

•  Evaluate  Current  Environment 

•  Establish  Objectives 

•  Provide  Access  to  Information 

Develop  Common  Understanding 

•  Review  Future  Requirements 

•  Evaluate  Recommended  Solutions 

•  Examine  Feasibility  Issues 

Expand  Advocacy  Network 

•  Identify  Implementation  Agencies 

•  Select  Appropriate  Forums 

•  Communicate  Ihe  Plans 

Prepare  Implementation  Plan 

Define  Activity  Descriptions 

•  Establish  Implementation  Guidelines 

•  Establish  Evaluation  Criteria 

•  Develop  Implementation  Procedures 

Develop  Organization  Plan 

•  Confirm  Major  Milestones 

•  Establish  Transition  Plan 

•  Identify  Organizational  Responsibilities 

Establish  Constituency 

•  Gain  Management  Acceptance 
of  Plan 

•  Obtain  a  Commitment  for  Execution 

Create  Documentation 

•  Establish  Goals 

•  Define  Resource  Requirements 

•  Recommend  Technologies 

•  Define  Organizational  Impact 

•  Establish  Financial  Parameters 


FIGURE  1-5.  MODULAR  PLANNING  PROCESS  OVERVIEW 


1-8 


Efforts  to  understand  software  maintenance  have  not  diminished.  Unique  methods  of  im¬ 
pressing  the  importance  of  support  issues  have  been  developed.  As  recently  as  1987,  Blue 
Two  visits  (so  designated  by  virtue  of  the  goal  of  the  effort,  which  was  to  allow  industry  to 
view  the  maintenance  process  through  the  eyes  of  the  Air  Force  two-striper)  were  conducted 
to  make  industry  engineers  aware  of  the  importance  of  supportability,  maintainability,  test- 
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Several  Air  Force  programs  have  been  established  to  keep  pace  with  technology.  Most  prom¬ 
inent  is  the  Software  Engineering  Institute  (SEI)  at  Carnegie  Mellon  University.  Founded 
in  1984,  the  SEI  is  a  federally  funded  research  center  sponsored  by  the  DoD.  Five  programs 
research  DoD  aspects  of  software:  the  Software  Engineering  Process  Program,  the  Engineer¬ 
ing  Methods  Program,  the  Software  Systems  Program,  the  Education  Program  and  the  Tech¬ 
nology  Transition  Program. 

A  variety  of  organizations  have  also  taken  a  keen  interest  in  the  direction  of  software  mainte¬ 
nance.  In  particular  the  Society  of  Logistics  Engineers  (SOLE)  conducted  a  symposium  in 
1989,  focusing  on  the  issue  of  software  logistics.  According  to  one  definition  at  the  sympo¬ 
sium,  software  logistics  can  be  defined  as  “the  selective  application  of  the  integrated  logistic 
support  process  to  the  system  software  element”.  This  symposium  generated  32  recommen¬ 
dations  relating  to  management,  technology  and  training  for  software  logistics.  Overall,  the 
increased  value  of  LSA  for  software  was  stressed,  as  evidenced  by  the  recommendation  that 
DODD  5000.39  be  revised  to  integrate  software  life  cycle  requirements  within  the  ILS  pro¬ 
cess. 

Today,  the  vast  majority  of  Air  Force  software  documentation  at  AUC  libraries  is  paper- 
based,  which  makes  it  difficult  to  use  in  software  maintenance  and  modifications.  Frequent¬ 
ly,  documentation  was  not  acquired,  cannot  be  found,  or  contains  insufficient  information  to 
expeditiously  complete  software  maintenance  and  modifications.  From  a  cost  perspective, 
PDSS  represents  80%  of  the  software  life  cycle  costs.  Without  sufficient  documentation, 
systems  are  becoming  unsupportable.  This  affects  the  potential  system  life  of  weapon  sys¬ 
tems,  reduces  responsiveness  to  mission-critical  software  change  requirements,  and  in¬ 
creases  labor  costs  for  maintenance  and  modifications.  While  Ada  implementation  was 
meant  to  provide  a  degree  of  design  and  language  standardization,  the  validation  efforts  con¬ 
ducted  at  the  ALCs  for  this  report  show  only  a  small  percentage  of  Ada  code.  For  the  most 
part,  the  ALCs  will  be  tasked  to  maintain  a  variety  of  applications  across  several  languages 
and  platforms  within  each  weapon  system. 

1.8  REPORT  ORGANIZATION 

The  report  is  organized  to  present  sequentially  an  overview  of  the  organizational  environ¬ 
ment,  structured  analysis  models,  and  the  findings  identified.  Section  2  assesses  the  organiza¬ 
tional  environment  and  describes  howSPD  is  used.  Section  3  summarizes  the  Input,  Control, 
Output,  Mechanism  (ICOM)  Definition  (IDEF0)  model  analysis.  Section  4  presents  the  find¬ 
ings  identified  during  the  development  of  the  report.  Four  appendices  provide  additional 
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detail  to  the  major  sections.  Appendix  A  summarizes  major  studies  of  Air  Force  software 
problems  since  the  late  1970s  as  well  as  related  initiatives  that  are  within  the  scope  of  the  SPD 
program.  Appendix  B  presents  the  detailed  IDEFq  diagrams  with  related  text  that  describes 
the  process.  Appendix  C  is  a  bibliography  of  the  referenced  regulations,  standards,  and  other 
related  documents.  Appendix  D  lists  the  points  of  contact  for  this  report. 

1.9  SUMMARY 

Given  the  growth  of  weapon  system  software,  and  the  problems  associated  with  the  manage¬ 
ment  of  SPD,  this  CALS  module  will  provide  a  logical  transition  to  the  digital-based  man¬ 
agement  of  SPD.  The  SPD  Current  Environment  Report  identifies  the  current  Air  Force  pro¬ 
cess  for  developing  and  fielding  MCCR  embedded  computer  software  systems.  It  also 
identifies  the  organizations  who  are  either  responsible  for  the  development  of  SPD,  or  de¬ 
pendant  upon  SPD  to  adapt  to  changing  mission  requirements.  Findings  presented  begin  to 
identify  potential  CALS  opportunities.  In  summary,  SPD,  like  PDD,  AFTOMS  and  LSA,  will 
provide  the  opportunity  to  provide  quality  SPD  technical  information  at  the  right  place  and 
at  the  right  time. 
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SECTION  2:  ORGANIZATIONAL  ASSESSMENT 


2.1  INTRODUCTION 

The  focus  of  the  SPD  Organizational  Assessment  is  on  organizations  that  support  the  receipt, 
distribution,  storage,  use  and  configuration  of  SPD. 

2.1.1  Purpose 

The  purpose  of  the  Organizational  Assessment  is  threefold:  to  identify  Air  Force  organiza¬ 
tions  involved  in  SPD,  to  formulate  SPD- related  functional  descriptions  of  each  organization, 
and  to  identify,  through  matrix  analysis,  the  many  different  variables  that  affect  the  SPD  orga¬ 
nizational  environment. 

2.1.2  Scope 

Included  in  the  Organizational  Assessment  are  organizations  currently  involved  with  the  de¬ 
sign,  implementation,  and  testing  of  five  of  the  nine  categories  of  MCCR  software:  OFP.  EW 
C-E,  ATD,  and  ATE,  during  the  acquisition  phase  of  the  weapon  system  life  cycle.  Also  in¬ 
cluded  are  organizations  currently  involved  in  the  maintenance  and  modification  of  this  soft¬ 
ware  during  the  operational  phase  of  the  life  cycle. 

2.1.3  Approach 

The  Organizational  Assessment  is  based  on  site  visits  and  a  review  of  applicable  documenta¬ 
tion;  i.e.  FDD  Current  Environment  Report ,  Air  Force  Regulations  and  Missions,  organiza¬ 
tional  regulations,  and  other  relevant  documentation. 

The  Organizational  Assessment  is  divided  into  three  sections.  Section  2.2  identifies  the  orga¬ 
nizations  that  receive,  distribute,  store,  use,  and  configure  SPD  and  outlines  their  responsibi¬ 
lities.  Section  2.3  assesses  the  organizations  and  their  responsibilities  against  two  SPD  vari¬ 
ables:  MCCR  category  and  software  life  cycle  function.  Matrix  analysis  is  then  used  to  show 
how  each  variable  affects  the  SPD  current  environment.  Organizational  conclusions  are  pres¬ 
ented  in  Section  2.4. 

2.2  ORGANIZATIONAL  ROLES  AND  RESPONSIBILITIES 

The  SPD  organizational  environment  is  made  up  of  multiple  Air  Force  Commands,  organiza¬ 
tions  within  the  commands,  and  other  agencies,  all  of  whom  are  involved  in  the  receipt,  distri¬ 
bution,  storage,  use  and  configuration  management  of  SPD.  The  approach  taken  in  this  re¬ 
port  is  to  assign  relevant  organizations  and  agencies  into  four  categories  (FIGURE  2-1). 
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FIGURE  2-1.  SPD  ORGANIZATIONAL  ASSESSMENT  SCOPE 

Roles  and  responsibilities  for  each  of  these  categories  are  discussed  in  Sections  2.2.2  through 
2.2.5.  FIGURE  2-2  represents  the  SPD  organizational  structure.  It  is  made  up  of  multiple 
Air  Force  Commands,  organizations  within  commands,  and  other  agencies  involved  in  the 
acquisition  and  support  process. 

2.2.1  HQ  USAF 

AFR  800-14,  Acquisition  Management  for  Life  Cycle  Management  of  Computer  Resources  in 
Systems,  outlines  responsibilities  for  MCCR  software  acquisition  and  operational  support  for 
HQ  USAF  and  organizations  within  the  USAF.  Managerial  responsibilities  include:  PMD 
input,  program  management  definition,  program  guidance  and  direction,  and  program  or  sys¬ 
tem  acquisition  and  support  responsibility  designation. 

2.2.2  Implementing  Command 

The  Implementing  Command  has  overall  responsibility  for  developing  a  weapon  system  pro¬ 
gram.  Usually  the  task  is  contracted  out  and  the  Implementing  Command  is  responsible  for 
initiating  and  monitoring  the  contractor’s  development  of  the  system. 

AFSC  is  most  often  the  Implementing  Command  for  MCCR  software.  However,  other  com¬ 
mands  sometimes  take  on  acquisition  responsibilities  for  weapon  systems  software.  For  ex¬ 
ample,  Air  Force  Logistics  Command  (AFLC),  Air  Force  Communications  Command 
(AFCC),  and  Air  Force  Space  Command  (AFSPACECOM)  sometimes  manage  the  acquisi¬ 
tion  of  major  modifications  for  MCCR  software.  FIGURE  2-3  illustrates  the  organizational 
structure  of  AFSC  as  the  Implementing  Command.  AFLC,  AFSPACECOM,  and  AFCC  are 
discussed  in  sections  2.2.3,  2.2.4.4,  and  2.2.5.2. 

2.2.2.1  Air  Force  Systems  Command  (HQ  AFSC) 

AFSC  plays  a  major  role  in  the  research,  development,  testing,  and  implementation  of  weap¬ 
on  systems  technology.  AFSC’s  primary  mission  is  to  advance  aerospace  technology,  apply  it 
to  operational  aerospace  systems  development  and  enhancements,  and  to  acquire  qualita¬ 
tively  superior,  cost-effective,  and  logistically-supportable  aerospace  systems.  AFSC  is  also 
responsible  for  ensuring  that  system  support  disciplines  and  elements  are  improved  and  prop¬ 
erly  integrated  into  the  system  engineering  and  managing  process. 
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FIGURE  2-2.  SPD  ORGANIZAnONAL  STRUCTURE 


FIGURE  2-3.  IMPLEMENTING  COMMAND  INFRASTRUCTURE 

AFSC  plays  a  major  role  in  the  acquisition,  use,  and  management  of  SPD.  It  focuses  primari¬ 
ly  on  the  contractor’s  development  of  SPD.  HQ  AFSC,  issues  a  document.  Form  56,  to  pro¬ 
vide  direction  to  subordinate  organizations.  AFSC  also  provides  guidance  and  direction  to 
product  divisions,  laboratories,  and  to  development  and  test  centers. 

2.2.2.2  Product  Divisions 

The  six  Product  Divisions  within  AFSC,  all  of  which  relate  to  SPD  and  provide  weapon  sys¬ 
tems  acquisition  support,  are:  Aeronautical  Systems  Division  (ASD),  Electronic  Systems  Di¬ 
vision  (ESD),  Ballistic  Systems  Division  (BSD),  Munitions  Systems  Division  (MSD),  Space 
Systems  Division  (SSD),  and  Human  Systems  Division  (HSD).  Product  Divisions  provide 
programmatic  support  for  developing,  testing,  and  acquiring  weapon  systems.  As  part  of  their 
responsibilities.  Product  Divisions  ensure  that  advanced  technology  is  applied  to  MCCR  soft¬ 
ware. 

The  six  product  divisions  contribute  to  the  development  of  MCCR  software.  Division  re¬ 
sponsibilities  are  summarized  below. 

•  ASD  -  ASD  is  a  major  AFSC  organization  located  at  Wright-Patterson  AFB, 
OH.  ASD  supports  and  develops  SPD  for  aerospace  systems  software.  The 
division  also  directs  the  design,  development,  and  acquisition  of  aerospace  sys¬ 
tems,  i.e.,  fighters,  bombers,  transports,  aerial  tankers,  tactical  reconnaissance 
aircraft,  manned  vehicles,  long  and  short  range  air-to-surface  missiles,  simu¬ 
lators,  reconnaissance  and  electronic  warfare  systems,  and  aircraft  engines. 

•  ESD  -  ESD  is  located  at  Hanscom  AFB,  MA,  and  develops  acquires,  and  deliv¬ 
ers  electronic  systems  and  equipment  for  the  command,  control,  communica¬ 
tions  and  intelligence  (C3I)  functions  of  aerospace  forces.  An  example  of  an 
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ESD-developed  system  is  the  Ballistic  Missile  Early  Warning  System  Air  Force/ 
Army  radar  used  to  detect,  track,  and  direct  weapons  against  stationary  or  slow 
moving  ground  and  airborne  targets.  ESD’s  testing  responsibilities  include 
managing  the  Strategic  Defense  Initiative  Battle  Management  C3  National 
Testbed.  The  Rome  Air  Development  Center  (RADC),  discussed  in  Section 
2. 2. 2. 3,  is  assigned  to  ESD. 

•  BSD  -  BSD  is  located  at  Norton  AFB,  CA,  and  develops  ballistic  missi'e  sys¬ 
tems  and  subsystems,  including  the  Peacekeeper  Intercontinental  Ballistic  Mis¬ 
sile  (ICBM).  In  addition,  BSD  manages  the  research  and  development  of  the 
small  ICBM.  On  2  April  1990  the  BSD  will  become  the  Ballistic  Missile  Orga¬ 
nization  (BMO)  under  the  SSD. 

•  MSD  -  MSD  is  located  at  Eglin  AFB,  FL.  The  division  plans,  researches,  de¬ 
velops,  and  acquires  conventional  air  armaments,  and  tests  and  evaluates  ar¬ 
mament  and  electronic  combat  systems  and  related  equipment.  The  mission 
area  involves  lifecycle  responsibility  for  air  armaments.  In  conjunction  with 
MSD  development  and  testing  of  weapon  systems,  the  Air  Force  Tactical  Air 
Warfare  Center  and  the  33rd  Tactical  Fighter  Wing,  co-located  at  Eglin  AFB, 
offer  supporting  expertise  in  the  tactical  applications  of  the  weapons. 

•  SSD  -  SSD  is  located  at  Los  Angeles  AFB,  CA,  and  manages  the  majority  of 
the  nation’s  military  space  systems.  Responsibilities  include  maintaining 
space-based  communications,  meteorological,  navigational,  and  surveillance 
systems  in  support  of  combat  forces  (on  the  ground,  at  sea,  and  in  the  atmo¬ 
sphere),  and  operating  the  national  test  ranges  and  launch  facilities  to  support 
space  and  missile  programs. 

•  HSD  -  HSD  is  located  at  Brooks  AFB,  TX,  and  is  the  primary  Air  Force  orga¬ 
nization  for  ensuring  that  Air  Force  systems  and  operations  are  designed  with 
human  capabilities  in  mind.  HSD  is  responsible  for  conducting  research  and 
development,  and  for  acquiring  specific  operational  support  programs  to  sup¬ 
port  its  mission. 

Within  each  of  the  product  divisions  there  are  numerous  System  Program  Offices  (SPOs), 
which  manage  specific  systems.  The  SPO  assumes  primary  management  responsibility  for  the 
system  being  acquired  and  prepares  the  Program  Management  Plan  (PMP)  for  AFSC  and 
HQ  US  AF  to  review.  Most  system  acquisition  efforts  are  contracted  out  to  contractors.  With 
assistance  from  the  laboratories,  test  organizations,  and  Air  Force  Plant  Representatives  Of¬ 
fice  (AFPRO),  the  SPO  is  responsible  for  the  following:  contract  preparation,  source  selec¬ 
tion,  contract  monitoring,  and  managing  the  turnover  of  the  weapon  system  to  AFLC  at  Pro¬ 
gram  Management  Responsibility  Transfer  (PMRT). 
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2.2.2.3  Development  and  Test  Organizations 

Development  and  test  organizations,  in  this  section,  include  only  those  organizations  that  ac¬ 
quire,  develop,  and  support  SPD.  These  organizations  can  report  directly  to  the  product  divi¬ 
sions.  Some  of  these  organizations  have  multiple  functions  and  missions. 

•  Air  Force  Flight  Test  Center  (AFFTC)  -  AFFTC,  located  at  Edwards  AFB,  CA, 
conducts  and  supports  flight  testing  and  evaluation  of  manned  aircraft,  re¬ 
search  vehicles  and  related  propulsion,  flight  control  avionics,  and  weapon  sys¬ 
tems  in  or  entering  the  Air  Force  inventory.  Similar  tests  and  evaluation  can 
also  be  carried  out  by  AFFTC  on  aircraft  belonging  to  other  U.S.  military  ser¬ 
vices  and  government  agencies,  and  on  aircraft  and  related  systems  of  certain 
foreign  governments.  AFFTC  tests  and  evaluates  remotely  piloted  vehicles 
and  Air  Force  versions  of  air  and  ground-launched  cruise  missiles.  AFFTC  has 
several  programs  currently  underway:  flight  testing  and  evaluation  of  the  B-1B 
bomber,  and  system  improvements  on  the  F-16  and  F-15  fighters  and  the  B-52 
bomber. 

•  RADC  -  RADC,  located  at  Griffiss  AFB,  NY,  is  the  principal  organization  for 
conducting  Air  Force  research  and  development  programs  related  to  C3I. 
Even  though  C3I  does  not  fall  within  the  scope  of  this  SPD  study,  RADC  sup¬ 
ports  other  programs  that  include  MCCR  software.  RADC,  which  reports  to 
ESD,  helps  demonstrate  and  acquire  selected  systems  and  subsystems  within  its 
area  of  expertise.  RADC  mission  areas  include:  photonics  research,  communi¬ 
cations,  electromagnetic  guidance  and  control,  surveillance  of  ground  and 
aerospace  objects,  intelligence  data  handling,  information  systems  technology, 
artificial  intelligence,  battle  management,  ionospheric  propagation,  solid  state 
sciences,  microwave  physics,  and  electronic  reliability,  maintainability,  and 
compatibility.  RADC  develops  and  studies  software  quality  and  reliability 
measures.  RADC  also  manages  an  STD-related  technology  development  pro¬ 
gram,  Software  Life  Cycle  Support  Environment  (SLCSE). 

•  Space  and  Missile  Test  Organization  (SAMTO)  -  SAMTO,  located  at  Vanden- 
berg  AFB,  CA,  reports  to  SSD.  SAMTO  manages  field-tests  and  launch  oper¬ 
ations  for  all  DOD  directed  space  programs  and  long  range  ballistic  research 
and  development  programs.  SAMTO  also  develops,  manages,  and  operates 
the  research  and  development  programs  through  the  Western  and  Eastern 
Space  and  Missile  Centers. 

o  Western  Space  and  Missile  Center  (WSMC)  -  WSMC,  located  at  Van- 
denberg  AFB,  C  A,  is  responsible  for  conducting  launch  and  launch  sup¬ 
port  of  research  and  development  ballistic  missile  testing  and  polar  or¬ 
biting  space  launches  for  DOD,  USAF,  and  other  agencies.  The 
Western  Test  Range  supports  ballistic  and  space  test  organizations.  The 
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range  also  supports  East  Coast  Space  Shuttle  operational  flight  tests 
and  other  aeronautical  tests,  employing  the  same  sensors  and  data  gath¬ 
ering  equipment  used  for  ballistic  flights. 

o  Eastern  Space  and  Missile  Center  (ESMC)  -  ESMC,  located  at  Patrick 
AFB,  FL,  is  responsible  for  conducting  launch  and  launch  support  acti¬ 
vities  of  manned  and  unmanned  space  launches  and  ballistic  missiles  for 
the  Air  Force,  DOD,  foreign  governments,  and  other  government  agen¬ 
cies.  ESMC  support  includes  the  initial  assembly,  checkout,  and  ground 
processing  for  launch  of  the  Trident  II  and  Pershing  II  missile  programs. 
Since  these  systems  contain  MCCR  software,  ESMC  is  responsible  for 
generating,  managing,  and  using  SPD.  In  addition,  ESMC  operates  Pa¬ 
trick  AFB. 

•  4950th  Test  Wing  -  The  4950th  Test  Wing,  located  at  Wright-Patterson  AFB, 
OH,  tests  weapon  systems.  The  Wing  conducts  flight  test  programs  on  military 
systems,  subsystems,  and  test  components;  operates  and  maintains  assigned 
test  aircraft  and  equipment;  performs  Class  II  (research  and  development^  air¬ 
craft  modification  design,  fabrication,  and  installation;  provides  research  tech¬ 
nical  photographic  services;  and  furnishes  flight  test  engineering  support  and 
technical  data  acquisition  services  for  specialized  missions  worldwide.  The 
wing  can  plan,  conduct,  evaluate,  and  report  on  a  wide  range  of  research  and 
development  flight  test  requirements,  an  activity  that  requires  the  creation, 
management  and  use  of  SPD. 

•  3246th  Test  Wing  -  The  Test  Wing  is  located  at  Eglin  AFB,  FL  and  is  part  of  the 
MSD.  The  Test  Wing’s  responsibilities  include  operating  and  monitoring  the 
ranges  and  facilities.  Equipment  tested  at  these  ranges  include:  aircraft  sys¬ 
tems,  subsystems,  missiles,  guns,  bombs,  rockets,  targets,  high  powered  radars 
and  airborne  electronic  countermeasures  equipment.  As  part  of  the  Test 
Wing’s  mission  it  operates  a  fleet  of  more  than  forty  aircraft  and  maintains  a 
multi-billion  dollar  complex  of  modern  instrumentation. 

•  6510th  Test  Wing  -The  Test  Wing  is  located  at  Edwards  AFB,  CA  and  carries 
out  the  AFFTC  mission.  The  Test  Wing  tests  and  evaluates  new  and  modified 
aerospace  systems.  In  addition,  the  Test  Wing  is  responsible  for  operating  the 
USAF  Test  Pilot  school  and  maintaining  the  Utah  Test  and  Training  Range 
(UTTR).  At  the  U  IT  R  many  test  and  developmental  flights  are  remotely  pi¬ 
loted. 

•  Air  Force  Office  of  Scientific  Research  (AFOSR)  -  The  Office  is  located  at 
Bolling  AFB,  DC  and  is  the  single  manager  of  Air  Force  basic  research.  It 
awards  grants  and  contracts  for  research  directly  related  to  Air  Force  needs. 
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•  Arnold  Engineering  Development  Center  (AEDC)  -  The  Center  is  located  at 
Arnold  AFB,  TX,  and  operates  the  largest  and  most  advanced  complex  of  aero¬ 
space  flight  simulation  test  facilities.  AEDC’s  mission  is  to  test  aircraft,  mis¬ 
siles,  and  space  systems  using  flight  conditions  experienced  during  operational 
missions.  The  Center  helps  MCCR  software  developers  qualify  systems  for 
flight,  improve  designs,  and  establish  performance  levels  before  production. 
The  center  assists  in  troubleshooting  and  reduces  development  time  and  cost. 

•  Consolidated  Space  Test  Center  (CSTC)  -  The  Center  is  located  at  Onizuka 
AFB,  C  A  The  center  supports  DOD  research  and  development  of  spacecraft 
and  performs  launches,  checkout,  test,  and  development  support  for  DOD 
space  shuttle  payloads,  upper  stages,  and  experiments.  CSTC  performs  on-or¬ 
bit  tracking,  data  acquisition,  and  command  and  control  of  DOD  space  ve¬ 
hicles. 

2.2.2A  Laboratories 

Laboratories  are  responsible  for  research  and  development  of  technologies.  They  assist  the 
Product  Divisions  by  performing  operational  flight  testing,  installing  new  weapon  systems, 
and  modifying  programs.  The  laboratories  generate  and  use  SPD. 

'  Air  Force  Space  Technology  Center  (AFSTC)  -  AFSTC,  located  at  Kirtland 
AFB,  NM,  works  through  AFSC  and  AFSPACECOM  to  provide  research  re¬ 
sults  for  future  systems  needs,  and  to  identify  key  technology  areas  for  long 
range  plans.  AFSTC  directs  the  following  three  AFSC  laboratories: 

o  Air  Force  Weapons  Laboratory  (AFWL)  -  AFWL,  located  at  Kirtland 
AFB,  NM,  conducts  AFSC  non-conventional  weapons  research  and  de¬ 
velopment  in  high-energy  laser  technology,  advanced  weapon  con¬ 
cepts,  and  nuclear  weapon  technology.  The  non-conventional  weapons 
research  and  development  includes  MCCR  software. 

o  Air  Force  Astronautics  Laboratory  (AFAL)  -  AFAL  is  located  at  Ed¬ 
wards  AFB,  C  A  The  laboratory  conducts  research  and  undertakes  ad¬ 
vanced  development  and  exploratory  programs  on  space  and  rocket 
propulsion  technologies.  Research  and  development  efforts  focus  on 
improving  rocket  test  techniques  and  instrumentation. 

o  Air  Force  Geophysics  Laboratory  (AFGL)  -  The  Laboratory  is  located 
at  Hanscom  AFB,  MA  ,\FGL  is  the  center  for  research,  exploratory 
development,  and  advanced  technology  development  on  earth,  atmo¬ 
sphere  and  space  environments. 

•  Wright  Research  and  Development  Center  (WRDC)  -  WRDC,  located  at 
Wright-Patterson  AFB,  OH,  conducts  and  supports  research,  exploratory  de¬ 
velopment,  and  advanced  technology  development  of  MCCR  software. 
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WRDC  is  responsible  for  enhancing  and  integrating  the  technologies  of  the 
following  four  laboratories — Aero  Propulsion  Laboratory,  Avionics  Labora¬ 
tory,  Flight  Dynamics  Laboratory,  and  Materials  Laboratory. 

o  Aero  Propulsion  Laboratory  -  The  Aero  Propulsion  laboratory  con¬ 
ducts  research  and  development  in  the  areas  of  aerospace  power,  air 
breathing  propulsion,  fuels  and  lubricants.  The  laboratory  analyzes 
technology  for  potential  Air  Force  Weapon  Systems:  advanced  propul¬ 
sion  concepts,  ducted  rockets,  and  ramjet  engines.  There  is  also  an 
aggressive  in-house  program  to  maintain  technical  expertise,  verify 
contract  findings,  and  exploit  new  opportunities. 

o  Avionics  Laboratory  -  The  Avionics  laboratory  conducts  research  and 
development  for  navigation,  surveillance,  reconnaissance,  electronic 
warfare,  fire  control,  weapon  delivery,  communications,  systems  archi¬ 
tecture,  information  and  signal  processing  and  control,  subsystems  inte¬ 
gration  software,  and  electromagnetic  devices.  The  laboratory’s  goal  is 
to  provide  a  broad  technology  base  for  future  systems  and  ensure  that 
these  applications  are  implemented  to  satisfy  Air  Force  aerospace 
needs.  The  Avionics  laboratory  works  on  new  technological  tools  and 
other  SPD  to  forecast  technologies  for  future  system  development. 
Currently,  the  lab  is  employing  expert  systems  and  parallel  processing  as 
part  of  a  research  program  called  Advanced  Digital  Radar  Imagery  Ex¬ 
ploration  System  (ADRIES). 

o  Flight  Dynamics  Laboratory  -  The  Right  Dynamics  laboratory  is  pri¬ 
marily  responsible  for  developing  flight  vehicle  technologies,  i.e.,  flight 
simulators,  performance  analysis,  configuration  synthesis,  and  technol¬ 
ogy  integration. 

o  Materials  Laboratory  -  The  Materials  Laboratory  conducts  programs 
in  materials,  exploratory  development,  and  manufacturing  technology. 
Current  areas  of  interest  include  computer-integrated  manufacturing, 
robotics,  smart  processing,  and  flexible  automated  batch  manufactur¬ 
ing. 

2.2.2.S  Other  AFSC  Divisions  and  Offices  Related  to  SPD 

Most  system  demonstration  and  development  efforts  are  contracted  out:  the  Implementing 
Command’s  strategy  must  therefore  involve  request  for  proposal,  source  selection,  and  man¬ 
agement.  The  following  organizations  assist  with  these  tasks. 

•  Air  Force  Contract  Management  Division  (AFCMD)  -  The  AFCMD  at  Kirt- 
land  AFB,  NM,  is  responsible  for  DOD  contract  management  activities  in  25 
major  contractor  plants  and  other  contractor  facilities  assigned  to  the  Air 
Force.  Its  primary  mission  is  to  evaluate  contractor  performance  and  manage 
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the  administration  of  active  contracts.  Although  the  AFCMD  does  not  appear 
to  relate  directly  to  SPD  (since  SPD  is  not  generated  specifically  for  AFCMD 
use)  the  division  uses  SPD  to  ensure  that  standardization  i  adequately  ad¬ 
dressed  throughout  the  system  life  cycle. 

•  AFPRO  -  AFPRO  is  the  on-site  office  assigned  by  the  AFCMD  to  ensure  that 
the  contractors  are  meeting  their  obligations.  Even  though  AFPROs  are  under 
the  administrative  control  of  the  AFCMD,  a  Memorandum  of  Agreement 
(MO  A)  is  often  established  with  the  SPO.  AFPRO  is  primarily  implemented  at 
major  defense  contractors  (e.g.  Boeing,  Northrop)  where  the  Air  Force  has  on¬ 
going  full  scale  development  activities.  The  AFPRO  has  a  broad  scope  of  re¬ 
sponsibilities  covering  all  aspects  of  the  Air  Force’s  contracts  with  the  contrac¬ 
tor. 

•  Operating  Laboratories  -  Operating  laboratories  are  located  at  the  contrac¬ 
tor’s  site  and  are  subdivisions  of  the  AFPRO.  The  laboratories  closely  moni¬ 
tor  the  contractor’s  activities  using  SPD. 

2.2.3  Supporting  Command 

The  Supporting  Command,  usually  AFLC,  is  primarily  responsible  for  weapon  system  main¬ 
tenance.  There  are  five  basic  software  support  concepts  described  in  AFR  800-14  that  broad¬ 
ly  cover  the  spectrum  by  incorporating  varying  levels  of  AFLC,  Using  and  Operating  Com¬ 
mand  involvements.  The  software  concepts  are: 

•  AFLC  Support  -  AFLC  has  overall  System  Program  Manager  (SPM)  re¬ 
sponsibility,  performs  all  changes,  and  maintains  a  support  facility. 

•  AFLC  Support  with  User  Augmentation-  The  Using  Command  supports  a 
defined  set  of  parameters  or  data  that  allow  it  to  select  or  control  mission 
functions. 

•  Partitioned  Support-  The  Using  Command  supports  mission  software, 
while  AFLC  supports  system  software. 

•  User  Support  with  AFLC  Augmentation-  The  Using  Command  performs 
all  software  support  functions  except  distribution. 

•  User  Support-  The  Using  Command  has  the  same  software  support  re¬ 
sponsibilities  that  AFLC  has  in  the  AFLC  Support  concept. 

HQ  AFLC 

HQ  AFLC  located  at  Wright-Patterson  AFB,  OH,  formulates  policy  and  delegates  authority 
and  responsibility  to  other  AFLC  organizations.  HQ  AFLC  issues  a  Program  Action  Direc¬ 
tive  (PAD),  which  describes  the  responsibilities  of  AFLC  organizations  for  a  specific  pro¬ 
gram. 
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In  most  cases  AFLC  assumes  overall  management  responsibility  for  a  weapon  system  at 
PMRT.  AFLC  utilizes  its  network  of  five  ALCs  to  procure,  supply,  transport,  maintain,  and 
repair  the  system  to  ensure  weapon  system  combat  readiness.  Although  AFLC  is  generally 
the  Supporting  Command  for  a  weapon  system  it  sometimes  performs  acquisition  functions 
for  selected  modifications  to  weapon  system  software.  FIGURE  2-4  illustrates  the  Support¬ 
ing  Command  organizational  structure. 


FIGURE  2-4.  SUPPORTING  COMMAND  SPD  INFRASTRUCTURE 

Sections  2.2.3. 1  through  2.2.3. 5  discuss  the  responsibilities  of  organizations  that  support 
MCCR  software. 

2.2.3.1  Logistics  Operations  Center  (LOC) 

The  LOC,  co-located  with  HQ  AFLC  at  W-P  AFB,  OH,  monitors  technical  policy  established 
by  the  HO  AFLC,  assures  readiness  and  supportability  of  weapon  systems  required  to  support 
USAF  operational  plans,  ensures  that  all  related  systems,  processes,  and  plans  are  oriented  to 
sustain  war  plans  objectives,  and  advocates  support  of  program  requirements  in  AFLC. 
USAF,  and  DOD. 

2.2.3.2  Aerospace  Guidance  and  Metrology  Center  (AGMC) 

The  AGMC,  located  at  Newark  AFB,  OH,  is  the  only  center  within  the  Air  Force  that  pro¬ 
vides  repair  and  engineering  services  for  missile  and  aircraft  inertial  guidance  and  navigation 
systems,  and  for  certain  aircraft  displacement  gyroscopes.  The  center  also  provides  a  wide 
scope  of  engineering  consulting  services  on  inertial  guidance  systems  to  the  Air  Force  and 
ether  DOD  agencies.  AGMC  is  responsible  for  repairing  the  inertial  guidance  and  naviga¬ 
tion  systems  for  various  Air  Force  weapon  systems,  and,  through  interservice  agreements,  re¬ 
pairing  inertial  guidance  and  navigation  components  on  systems  acquired  by  the  Navy  and 
Army. 

2.2.3.3  Acquisition  Logistics  Division  (ALD) 

The  ALD,  located  at  W-P  AFB  is  subordinate  to  AFLC  .  ALD’s  MCCR  responsibility  is  to 
improve  Air  Force  readiness  and  to  reduce  life  cycle  costs  by  assuring  that  supportability. 
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reliability,  and  maintainability  are  considered  during  the  entire  weapon  system  life  cycle.  The 
ALD  provides  logistics  program  management,  engineering,  and  technical  analysis,  as  well  as 
centralized  logistics  expertise  to  AFLC  and  AFSC.  The  support  ALD  provides  to  other  orga¬ 
nizations  is  imperative  to  improving  the  software  maintenance  environment.  Logistics  man¬ 
agers  require  assistance  from  ALD  to  provide  experienced  specific  software  support  expertise 
and/or  supply  needed  or  trained  manpower.  The  ALD  provides  resources  through  the 
Deputy  Program  Manager  for  Logistics  (DPML),  who  works  with  other  SPO  organizations  to 
ensure  logistics  concerns  are  being  met.  In  September  1989  ALD  chartered  a  Supportable 
Software  Acquisition  Group  that  resulted  in  publication  of  the  Supportable  Software  Acquisi¬ 
tion  Guide  in  October  1989.  This  guide  contains  many  useful  approaches  relating  to  the  ac¬ 
quisition  of  SPD. 

ALD  personnel  are  sometimes  assigned  to  AFSC  laboratories  to  ensure  that  programs  in  ear¬ 
ly  phases  of  development  consider  logistics  issues.  In  addition,  ALP  works  jointly  with  the 
ASD  to  support  the  Joint  Technology  Insertion  Program  (JTIP)  Office.  JTIP  has  two  activi¬ 
ties;  Productivity,  Reliability,  Availability  and  Maintainability  (PRAM)  and  Reliability  and 
Maintainability  Technology  Insertion  Program  (RAMTIP).  PRAM  invests  in  cost  reduction 
projects  by  incorporating  the  latest  technology  into  operational  weapon  systems  and  support 
equipment.  RAMTIP  invests  in  laboratory  technologies  that  have  not  matured,  making  the 
technologies  available  much  sooner  than  they  would  be  through  the  normal  development 
cycle. 

2.2.3  4  Aerospace  Maintenance  and  Regeneration  Center  (AMARC) 

AMARC,  located  at  Davis-Monthan  AFB,  AZ,  is  the  single  manager  for  the  storage,  recla¬ 
mation,  return  to  flying  status,  and  disposition  of  all  aircraft  and  specified  missiles  not  cur¬ 
rently  required  in  the  DOD  operational  inventory.  The  center  can  also  preserve,  store,  and 
maintain  the  MCCR  software  systems  in  the  aerospace  vehicles,  provide  rapid  withdrawal  of 
parts,  or  return  whole  aircraft  to  flying  status  to  meet  military  needs. 

2.2.3.5  Air  Logistics  Centers  (ALCs) 

Five  ALCs  provide  the  majority  of  support  functions  for  MCCR  software  post-PMRT.  Each 
ALC  has  major  directorates,  divisions,  and  branches  that  acquire,  manage,  and  use  SPD. 
ALC  responsibilities  include  depot-level  maintenance  and  support  of  weapon  systems  and 
commodities,  respectively.  The  SPMs,  located  at  the  ALCs,  are  responsible  for  managing 
specific  weapon  systems.  The  SPM  is  designated  by  the  organization  within  the  Air  Force 
Supporting  Command  that  has  been  assigned  program  management  responsibility  according 
to  the  HQ  US  AF  PMD.  The  SPM  establishes,  directs,  and  controls  the  acquisition  of  SPD 
and  manages  the  software  support  programs  for  major  applications. 

FIGURE  2-5  illustrates  the  five  ALCs,  and  the  directorates  that  relate  to  SPD  within  each  of 
those  ALCs. 
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FIGURE  2-5.  ALC  SPD  INFRASTRUCTURE 
ALC  DIRECTORATES,  DIVISIONS  AND  BRANCHES 

MCCR  software  support  functions  are  not  limited  to  one  directorate  or  branch  within  each 
ALC,  but  are  dispersed  across  many  different  directorates,  branches,  and  divisions.  Unlike 
hardware,  the  software  organizational  environment  is  structured  so  that  organizations  are 
aligned  according  to  their  affiliation  with  a  specific  weapon  system  rather  than  a  particular 
function. 

The  PACER  STRIDE  initiative  recently  prompted  a  reorganization  of  the  Directorate  of 
Maintenance  (MA)  and  the  Directorate  of  Material  Management  (MM)  at  the  ALCs.  The 
initiative  hopes  to  resolve  some  of  the  shortcomings  of  the  original  organizational  structure 
by: 


•  Awarding  the  SPMs  the  necessary  authority  to  fulfill  their  responsibility. 

•  Making  the  organizational  structure  at  the  different  ALCs  more  consistent. 

•  Facilitating  the  implementation  and  integration  of  new  technologies. 

•  Improving  career  development  opportunities  for  computer  engineers. 

•  Placing  more  emphasis  on  quality  and  less  on  time  schedules. 

The  reorganization  realigned  the  SPM  more  closely  with  the  weapon  system  and  its  programs, 
and  expands  SPM  authority,  so  that  the  SPM  now  has  responsibility  for  item  management 
of  weapon  system-specific  items.  In  addition,  many  of  the  functions  that  were  software  main¬ 
tenance-related  were  transferred  from  the  MM  directorate  into  the  MA  directorate.  The  re¬ 
sponsibility  to  attend  In-Process-Reviews  (IPRs)  and  Critical  Design  Reviews  (CDRs)  has 
been  typically  moved  from  the  Computer  Resources  Branch  (MMEC)  to  the  Software  Sup¬ 
port  Division  (MAS). 
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Even  though  the  PACER  STRIDE  initiative  applies  to  all  ALCs,  the  organizational  structures 
for  the  MM  and  M  A  directorates  are  not  consistent  across  the  five  ALCs.  For  example,  Whr- 
ner-Robins  ALC  (WR-ALC)  is  following  the  PACER  STRIDE  initiative  in  functionality,  but 
has  aligned  functions  to  organizations  that  differ  from  the  other  ALCs. 

Responsibilities  of  the  divisions,  directorates,  and  branches  that  relate  to  SPD  and  make  up 
the  Supporting  Command  are  described  in  Sections  2.2.3.5.1  through  2.2.3.5.5. 

2.2.3.5.1  Directorate  of  Maintenance  (MA) 

MA  is  primarily  responsible  for  management  of  the  depot-level  maintenance,  production  fa¬ 
cilities,  and  laboratories  used  in  the  modification,  local  manufacturing,  and  repair  of  Air 
Force  equipment.  MA  provides  support  to  the  SPM.  Even  though  the  MM  Directorate, 
discussed  in  the  following  section,  is  primarily  responsible  for  the  management  and  support  of 
MCCR  software  maintenance,  MA  is  the  Implementing  Directorate  for  MCCR  software 
maintenance.  Many  divisions  and  branches  within  MA  have  a  significant  role  in  the  develop¬ 
ment,  use,  or  management  of  SPD. 

FIGURE  2-6  illustrates  the  most  common  MA  infrastructure  for  SPD  at  the  ALCs.  The  Re¬ 
sources  Management  Division  (MAW),  Product  Division  (MAJ,  Quality  Assurance  Division 
(MAQ)  and  Software  Support  Division  (MAS)  are  the  MA  divisions  that  relate  to  MCCR 
software  and  will  be  discussed  in  this  section.  The  Product  Division  symbol  (MAJ  varies  in 
the  third  character  for  each  different  product  within  each  ALC.  The  other  division  symbols 
remain  constant  at  each  ALC. 


FIGURE  2-6.  DIRECTORATE  OF  MA  INFRASTRUCTURE 


•  MAW  -  MAW’s  primary  function  is  to  develop  the  directorate’s  policy  and 
plans  for  depot-level  maintenance:  facilities,  equipment,  and  skills  for  work¬ 
loading.  MAW  researches  and  reviews  engineering  drawings  and  specifica¬ 
tions,  then  works  with  HQ  AFLC  and  SPM  to  negotiate  schedules  and  plans 
and  to  monitor  the  depot-level  maintenance  posture  and  process.  The  division 
is  also  relevant  to  the  SPD  organizational  environment  because  it  is  responsi¬ 
ble  for  the  acquisition  of  user  manuals  and  additional  related  documents  for 
MCCR  weapon  systems.  According  to  AFR  800-21  for  ATE  software,  MAW 
serves  as  the  focal  point  for  Software  Support  Center  (SSC)  responsibilities. 
The  division  maintains  surveillance  of  the  SSC  workload  production  status,  and 
also  coordinates  directives,  correspondence,  project  studies,  and  requirements 
for  ATE  software. 

•  MA_  -  The  Product  Division  (MA_)  manages  the  requirements,  estimates 
source  selection  support,  and  provides  technical  input  and  logistics  planning 
for  the  weapon  system  and  end-item  acquisition  process.  The  division  has 
many  software  support  responsibilities.  It  provides  on-site  engineering  assis¬ 
tance  required  by  the  production  activity  to  identify  and  correct  software  defi¬ 
ciencies.  The  division  also  designs,  develops,  and  provides  new,  modified  test 
software,  and  updates  existing  avionics  system  software. 

•  MAQ  -  MAQ’s  primary  function  is  to  ensure  that  quality  products  are  gener¬ 
ated.  The  division  supports  the  pre-production  and  operational  planning 
phases  for  weapon  systems,  evaluating  the  product’s  integrity,  participating  in 
software  verification  and  validation  testing  and  reviews,  and  evaluating  the 
quality  of  MCCR  software  design.  MAQ  verifies  the  configuration  of  MCCR 
software  in  use  and  determines  if  the  system  has  met  the  defined  requirements 
and  generated  the  required  SPD  documents. 

•  MAS  -  MAS  supports  many  MCCR  software  maintenance  functions  and  pro¬ 
vides  software  maintenance  support  to  the  MM  directorate.  Under  the  PACER 
STRIDE  reorganization,  MAS  has  been  assigned  additional  responsibilities 
relating  to  SPD.  The  organizational  changes  under  the  PACER  STRIDE  ini¬ 
tiatives  have  not  been  formally  documented  in  regulations,  but  the  ALUs  have 
been  reorganized  and  assigned  the  new  responsibilities.  It  should  be  noted  that 
WR-ALC  does  not  have  an  MAS  division.  MAS  responsibilities  for  the  other 
ALUs  are  as  follows: 

o  Participate  in  the  Preliminaiy  Design  Reviews  (PDRs),  Critical  Design 
Reviews  (CDRs),  Computer  Resources  Working  Group  (CRWG),  and 
other  technical  interchange  meetings. 

o  Maintain  liaison  with  using  activities  to  identify  existing  support  prob¬ 
lems. 
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o  Develop  or  enhance  MCCR  software  to  correct  deficiencies  or  provide 
capabilities  related  to  systems  and  equipment. 

o  Provide  Configuration  Management  (CM)  support. 

o  Conduct  or  participate  in  formal  verification  and  validation  of  assigned 
computer  programs  to  support  other  Air  Force  agencies  during  weapon 
system  acquisition. 

The  three  branches  of  MAS  relating  to  SPD  are  as  follows: 

o  Software  Support  Branch  (MAST)  -  MAST  is  related  to  SPD  through 
its  involvement  in  test  software.  The  technical  support  capability  for 
Unit  Under  Test  (UUT)  software  is  assigned  by  Sacramento  ALC  (SM- 
ALC),  which  coordinates  the  test  software  support  with  the  MM  Direc¬ 
torate.  MAST  provides  centralized  software  engineering  expertise  to 
support  the  UUT  SPMs  requests.  On  request,  the  MAST  participates  in 
the  CRWG  and  the  production  of  the  Computer  Resources  Life  Cycle 
Management  Plan  (CRLCMP). 

o  Aircraft  Software  Development  Branch  (MASA)  -  MASA  provides 
maintenance  support  for  aircraft  software. 

o  Missile  Systems  Software  Branch  (MASM)  -  MASM  provides  mainte¬ 
nance  support  for  missile  systems  software. 

2.2.3.5.2  Directorate  of  Materiel  Management  (MM) 

MM  is  responsible  for  engineering  management  and  development,  and  for  controlling  the 
design  and  reliability  of  assigned  weapon  systems,  equipment,  and  modification  programs. 
MM  plays  a  major  role  in  supporting  MCCR  software.  FIGURE  2-7  illustrates  the  MM  orga¬ 
nizational  structure. 

•  Resource  Management  Division  (MMM)  -  MMM  acts  as  the  focal  point  for  de¬ 
veloping  automation  proposals  and  is  the  backup  chair  of  the  ALC  Configura¬ 
tion  Control  Board  (CCB),  in  the  absence  of  the  director  or  deputy  director. 
Within  the  division  there  are  branches  with  responsibilities  related  to  SPD. 

o  Logistics  Planning  Branch  (MMML)  -  MMML  uses  and  modifies  plan¬ 
ning  and  programming  documents  and  is  responsible  for  test  and  evalu¬ 
ation  task  planning  and  programming  support. 

o  Maintenance  Modification  Branch  (MMMM)  -  MMMM  determines 
the  impacts  on  the  maintenance  and  modification  phases  of  logistics 
support  by  analyzing  SPD  (planning  documents  and  data)  for  assigned 
items  and  systems. 

o  Requirements  Branch  (MMMR)  -  MMMR  ensures  that  the  weapon 
system  requirements  are  accurately  identified  by  reviewing  and  revising 
SPD. 
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FIGURE  2-7.  DIRECTORATE  OF  MM  INFRASTRUCTURE 


•  Scientific  and  Technical  Division  (MME)  -  MME  is  the  primary  software  engi¬ 
neering  group.  The  division  has  a  direct  impact  on  SPD  since  it  develops  imple¬ 
mentation  procedures,  makes  software  engineering  design  changes,  and  man¬ 
ages  software/hardware  integration  support  facilities.  Within  MME  there  are 
several  branches  related  to  SPD.  However,  the  PACER  STRIDE  reorganiza¬ 
tion  has  recently  transferred  many  of  the  responsibilities  from  MME  to  MAS. 

o  Computer  Resources  Branch  (MMEC)  -  MMEC  is  responsible  for 
managing  SPD.  The  branch  ensures  that  support  requirements  are  met 
and  that  technical  adequacy  is  considered. 

o  Operations  and  Support  Branch  (MMEO)  -  MMEO  is  responsible  for 
supporting  documentation  management.  Responsibilities  include  dis¬ 
tribution  and  control  of  data.  In  addition,  the  branch  participates  in  ad¬ 
vance  procurement  data  reviews.  The  Software  Control  Centers  (SCC) 
resides  within  MMEO.  The  SCC  is  a  repository  (largely  paper)  for  soft¬ 
ware  documentation.  It  should  be  noted  that  WR-ALC  does  not  have 
an  MMEO  branch;  consequently  SCC  resides  in  the  MMD  division. 

•  Item  Management  Division  (MMI)  -  MMI  ensures  that  the  desii  ed  perform¬ 
ance  of  assigned  items  is  maintained.  The  division  oversees  support  activities 
to  ensure  that  all  of  the  different  variables  (i.e.  software  modification  changes 
required  when  supporting  a  weapon  system)  are  coordinated.  Under  the  PAC- 
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ER  STRIDE  initiative  MMI  is  responsible  for  item  management  functions  re¬ 
lated  to  general  items,  while  item  management  functions  of  weapon-specific 
items  have  been  transferred  to  the  SPM. 

o  Material  Support  Branch  (MMIS)  -  MMIS  participates  in  the  CRWG, 
which  develops  the  CRLCMP. 

o  Engineering  and  Reliability  Branch  (MMIR)  -  MMIR  provides  engi¬ 
neering  and  technical  support  for  assigned  items  to  all  Air  Force,  Air 
Force  Reserves  (AFRES)  and  Air  National  Guard  (ANG)  activities. 
Engineering  and  technical  management  responsibilities  include  review¬ 
ing  documents  to  ensure  maintenance  concepts  are  up  to  date  and  de¬ 
termining  the  impact  of  the  concepts  on  technical  and  engineering  as¬ 
pects  of  logistics  support. 

•  Support  Division  (MMD)  -  MMD  manages  the  Technical  Order  process.  At 
WR-ALC,  the  MMD  is  responsible  for  the  Software  Control  Center  (SCC). 

•  Quality  Division  (MMQ)  -MMQ  ensures  that  weapon  systems  and  end  items 
are  meeting  quality  and  integrity  standards. 

•  System  Management  Division  (MMJ  -  MM_  serves  as  the  focal  point  for 
weapon  systems,  and  ensures  that  depot  level  maintenance  capability  is 
achieved  for  modified  items  assigned  to  the  weapon  systems.  Within  the  MM 
structure  resides  the  SPM  that  manages  the  weapon  system.  FIGURE  2-8  rep¬ 
resents  the  SPM  organizational  model.  Within  the  SPM  model  there  are  seven 
branches;  Requirements  Distribution  (MM  D),  Operations  (MM_M),  Produc¬ 
tion  Management  (MM_P),  System  Engineering  (MM_R),  Support  Branch 
(MM_S),  Acquisition  (MM_A),  and  International  Logisitics  (MMJ).  Three  of 
the  branches,  MM_S,  MM_A  and  MMJ,  are  optional  for  each  SPM.  MM_R, 
MM_D,  MM_P  and  the  Operations  Branch  will  be  discussed  in  more  detail  in 
this  section,  since  they  are  consistent  across  all  the  ALCs  and  SPMs  and  are 
relevant  to  SPD. 

o  System  Engineering  Branch  (MM_R)-  The  primary  function  of  MM_R 
is  to  determine  requirements  for  MCCR  software  data.  The  branch  at¬ 
tends  design  reviews  and  performs  engineering  analysis  to  determine 
requirements  for  modifications.  MM_R  performs  system  integration  to 
ensure  design  performance  and  compatibility.  In  addition,  MM_R 
manages  the  system  configurations  by  managing  and  approving  changes 
to  operational  flight  programs  and  associated  computer  programs. 
They  also  provide  engineering  reviews  and  approve  changes  to  comput¬ 
er  programs.  MM_R  ensures  that  support  equipment,  including  ATE 
software  and  test  adaptors,  satisfy  testing  requirements,  provides  sup- 
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port  during  OT&E,  and  provides  configuration  control  over  assigned 
systems. 


FIGURE  2-8.  MODEL  SPM  INFRASTRUCTURE 


o  Production  Management  Branch  (MM_P)  -  MM_P  ensures  that  depot 
level  maintenance  concepts  are  given  early  consideration  during  the 
conceptual  phases  of  system  and  subsystem  acquisition  by  establishing  a 
working  relationship  with  the  Implementing  and  Using  Commands 
through  the  Integrated  Logistics  Support  (ILS)  directorate.  The  branch 
also  reviews  planning  and  programming  documents  to  determine  their 
impact  on  maintenance  production  aspects  of  logistics  support 

o  Requirements  and  Distribution  Branch  (MM_D)  -  MM_D  institutes 
the  Procurement  Request  (PR)  and  ensures  that  approved  SPD  is  in¬ 
cluded.  It  also  supports  item  management  functions  by  acquiring  and 
maintaining  material  inventory  in  support  of  spares,  reprocurements 
and  modifications. 

o  Operations  Branch  (MM_M,H,0)  -  The  Operations  Branch  is  respon¬ 
sible  for  ensuring  that  the  weapon  system  and  assigned  end  items  main¬ 
tain  desired  operational  requirements  and  expectations. 

2.23.5.3  Directorate  of  Competition  Advocacy  (CR) 

CR  ensures  that  there  is  increased  competition  and  adequate  requisition  procedures  to  en¬ 
hance  the  operational  capability  of  weapon  systems.  The  directorate  reviews  the  Justification 
and  Approval  (J&A)  and  the  Statement  of  Work  (SOW)  of  proposed  MCCR  software  acqui¬ 
sition  and  support  contracts.  Currently,  few  software  modification  contracts  are  issued  com- 
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petitively,  requiring  minimal  CR  involvement.  This  is  due  to  /Jr  Force  reliance  on  the  origi¬ 
nal  developing  contractors’  knowledge  of  the  software  to  perform  the  modification  more 
quickly  and  effectively  and  also  to  the  Air  Force’s  not  having  procured  SPD.  This  offsets,  to 
some  degree,  the  cost  savings  from  competition. 

2.2.3.5.4  Directorate  of  Communications  -  Computer  Systems  (SC) 

SC  is  responsible  for  acquiring  and  controlling  computer  resources  and  technology  through¬ 
out  the  ALCs.  The  functions  relating  to  MCCR  software  appear  to  be  limited  due  to  SC’s 
focus  on  Information  Systems  (IS).  The  directorate  is  concerned  with  systems  that  are  devel¬ 
oped  for  the  managing  SPD,  i.e.  digitizing  data  and  operating  CASE  tools,  and  shouid  there¬ 
fore  be  considered  a  relevant  part  of  the  SPD  organizational  environment. 

2.2.3.5.5  Directorate  of  Contracting  and  Manufacturing  (PM) 

PM  covers  all  aspects  of  acquisition.  The  directorate’s  responsibilities  include  evaluating  po¬ 
tential  firms  for  contract  awards,  ensuring  timely  delivery  of  quality  supplies,  and  making  final 
payment  for  goods  and  services  delivered. 

2.2.4  Using  Commands 

The  Using  Commands  are  the  Air  Force  commands  that  assume  full  operational  responsibil¬ 
ity  for  the  weapon  system  after  turnover  to  the  Supporting  Command.  According  to  the  rele¬ 
vant  regulations  and  directives,  AFLC  is  primarily  responsible  for  software  support  that  can 
be  shared  with  or  delegated  to  the  Using  Command.  Even  though  documentation  supports 
the  trend  that  the  Using  Command  is  beginning  to  provide  total  or  parti  1  support  for  OFP, 
EW,  and  C-E  programs  within  Military  Airlift  Command  (MAC),  Tactical  Air  Command 
(TAC)  and  Strategic  Air  Command  («SAC),  it  was  verified  that  these  MAJCOMs  are  primarily 
supporting  changes  to  mission  software.  The  one  exception  is  AFSPACECOM;  the  command 
is  providing  major  software  maintenance,  and  in  addition  is  now  beginning  to  take  on  the 
acquisition  and  development  functions  of  weapon  systems  software.  FIGURE  2-9  illustrates 
the  model  Using  Command  SPD  infrastructure. 


FIGURE  2-9.  USING  COMMAND  SPD  INFRASTRUCTURE 
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Before  describing  the  SPD  roles  and  responsibilities  of  the  Using  Commands  the  software 
maintenance  role  needs  to  be  qualified.  This  is  accomplished  by  defining  two  types  of  MCCR 
software:  Mission  Software  (user-oriented)  and  Systems  Software  (hardware-oriented).  In 
addition,  a  model  ot  the  organizational  structure  of  MAC,  TAC  and  SAC  will  be  discussed  in 
detail. 

SOFTWARE  SUPPORT  CATEGORIES 

The  software  categories  are  defined  in  AFR  800-14  as  follows: 

•  Mission  Software  -  Designed  to  perform  user-oriented  tasks.  The  software  im¬ 
plements  tactics,  operational  concepts  and  operational  procedures.  Changes 
to  the  system’s  operational  mission,  tactics,  or  user  proceH  ares  often  require 
corresponding  changes  to  mission  software. 

•  System  Software  -  Allocates,  controls,  monitors  and  supports  the  system’s 
hardware  resources  (historically  hardware  tasks).  System  software  includes  op¬ 
erating  system  functions  (including  special  purpose  hardware  device  drivers), 
utilities,  and  generic  applications  such  as  Database  Management  Systems 
(DBMS).  The  System  software  manages  external  interfaces  to  pass  informa¬ 
tion  originating  in  mission  software.  System  software  translates  mission  soft¬ 
ware  requests  into  system  and  hardware  functions.  It  provides  system  data  into 
mission  software  for  processing.  Software  that  is  not  specifically  mission  soft¬ 
ware  can  be  defined  as  system  software. 

The  Using  Command  focuses  on  mission  software  maintenance,  with  the  exception  of  AF- 
SPACECOM,  which  is  also  involved  in  the  PDSS  development  and  maintenance  of  both 
MCCR  mission  and  system  software. 

ORGANIZATIONAL  STRUCTURE 

This  section  will  focus  on  Using  Commands.  The  organizational  structure  of  the  Using  Com¬ 
mands  are  very  similar.  There  are  four  divisions  relating  to  SPD:  Requirements  (XR),  Logis¬ 
tics  (LG),  Communication  Computers  (SC),  and  Operations  (DO).  Even  though  these  divi¬ 
sions  are  in  place  in  MAC,  SAC,  and  TAC,  the  functions  they  perform  are  not  consistent 
across  all  three  M  AJCOMS.  Maintenance  responsibilities  for  MCCR  software  are  dispersed 
across  several  divisions  and  are  often  aligned  with  the  weapon  system.  In  addition,  within  the 
Using  Commands  there  are  reorganizations  occurring  whereby  SPD-related  functions  are 
transferred  from  one  division  to  another,  i.e.,  at  MAC  SC  responsibilities  are  being  trans¬ 
ferred  to  XR.  FIGURE  2-10  is  a  model  of  the  SPD  organizational  structure  within  the  Using 
Commands. 

MAC,  TAC,  and  SAC  coordinate  mission  changes  for  MCCR  software  with  the  ALCs.  When 
major  modifications  are  required,  software  maintenance  is  managed  solely  by  the  ALC.  Us¬ 
ing  Command  personnel  revealed  that  MAC,  TAC  and  SAC  are  not  consistent  in  software 
maintenance  functions.  Even  though  it  is  documented  that  the  current  trend  is  to  have  the 
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Using  Command  maintain  software,  personnel  did  not  indicate  that  anything  more  than  mis¬ 
sion  software  changes  were  performed.  Extensive  MCCR  software  modifications  are  still 
managed  by  the  ALCs,  rather  than  MAC,  TAC  and  SAC. 


FIGURE  2-10.  MODEL  INFRASTRUCTURE  FOR  MAC,  TAC,  AND  SAC 

The  software  maintenance  role  of  the  divisions  within  the  Using  Commands  are  as  follows. 
The  Logistics  Division  (LG)  performs  maintenance  planning.  The  Requirements  Division 
(XR)  acquires  the  weapon  system  and  defines  requirements  for  the  software.  The  Operations 
Division  (DO)  operates  and  sometimes  performs  maintenance  on  the  mission  software.  The 
Communications  and  Computer  Division  (SC)  focuses  on  IS  software,  but  in  some  instances, 
performs  maintenance  on  MCCR  software.  The  task  of  performing  maintenance  within  the 
DO  is  characteristic  of  the  SPD  environment  within  the  Using  Command.  The  functions  are 
aligned  to  an  organization  due  to  its  affiliation  with  a  weapon  system  rather  than  a  particular 
function. 

In  most  cases,  the  Using  Commands  are  not  responsible  for  changing  the  source  code;  instead 
they  define  the  requirements,  make  maintenance  plans,  and  install  the  changes  for  mission 
software. 

Sections  2.2.4. 1  through  2. 2.4. 7  discuss  SPD  roles  and  responsibilities  of  the  Using  Com¬ 
mands  in  more  detail. 

2.2.4.1  Strategic  Air  Command  (SAC) 

SAC  has  been  designated  both  a  specified  Command  and  a  Single  Service  Command  under 
the  strategic  direction  of  the  President  and  Secretary  of  Defense.  SAC  has  responsibility  for 
strategic  aerospace  combat  and  must  provide  nuclear  capability  strong  enough  to  deter  an 
attack  on  the  United  States  or  its  allies.  The  Command’s  task  is  to  support  worldwide  conven¬ 
tional  power  projection  with  its  bombers  and  missiles.  HQ  SAC  is  located  at  Offuti  AFB,  NB. 
SAC  is  playing  an  increasing  role  in  maintaining,  developing,  and  acquiring  software  systems. 
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and  in  training  the  personnel  who  use  the  weapon  systems.  The  LG,  XR,  DO,  and  SC  direc¬ 
torates  provide  software  support. 

The  SC  organization  within  SAC  maintains  some  MCCR  software.  AFCC  personnel  are  ma- 
trixed  to  SAC’s  SC  organization  to  provide  MCCR  software  maintenance  resources.  Forex- 
ample,  within  SAC’s  SC  organization  is  the  Space  and  Satellite  Division  (SCZ),  which  sup¬ 
ports  Air  Force  satellite  programs.  SC’s  primary  responsibility  is  to  operate  the  system;  while 
the  Product  Division,  contractors  or  ALCs  coordinate  MCCR  software  maintenance.  The 
division  may  perform  minor  mission  changes  to  the  satellite  systems. 

The  LG  Division  performs  software  maintenance  functions  for  mission  software  and  installs 
the  changes  for  MCCR  software;  XR  defines  requirements  for  maintenance  and  acquisitions 
and  DO  operates  the  system  and  sometimes  performs  maintenance  functions.  The  AFLC 
provides  CM,  and  is  focal  to  the  software  maintenance  functions. 

2.2A.2  Military  Airlift  Command  (MAC) 

HQ  MAC  is  located  at  Scott  AFB,  IL.  MAC ’s  mission  is  to  maintain  the  military  airlift  system 
in  a  constant  state  of  readiness.  A  major  effort  of  MAC  that  demands  MCCR  support  require¬ 
ments  is  the  C-17.  MAC  is  performing  some  mission  changes  to  the  C-17  NAV/COM  system. 

Within  MAC  four  organizations:  SC,  XR,  LG  and  DO  support  MCCR  software.  Activities 
range  from  providing  plans  and  guidance,  to  down-loading  data  bases.  The  level  of  mainte¬ 
nance  performed  at  MAC  is  primarily  low-level  for  mission  software.  Between  MAC,  SAC, 
and  TAC,  MAC  maintains  the  least  amount  of  MCCR  software.  The  command  recently  was 
reorganized;  many  resources  and  functions  previously  assigned  to  SC  have  been  moved  under 
the  XR  Division.  The  SC  is  primarily  providing  IS  support  whereas  the  DO,  XR  and  LG  Divi¬ 
sions  are  providing  MCCR  software  support.  MAC’S  support  of  MCCR  software  is  not  fo¬ 
cused  to  one  organization  but  is  dispersed  across  the  entire  Using  Command  and  is  aligned 
with  the  various  weapon  systems. 

2.2A.3  Tactical  Air  Command  (TAC) 

TAC’s  mission  is  to  train,  equip,  and  maintain  combat-ready  forces  capable  of  rapid  deploy¬ 
ment  and  employment.  TAC’s  forces  are  organized  under  three  numbered  air  forces  and 
through  major  direct  reporting  units.  HQ  TAC  is  located  at  Langley  AFB,  VA.  TAC’s  1st  Air 
Force  manages  the  USAF  Air  Defense  Weapon  Center,  which  provides  specialized  air  de¬ 
fense  weapons  training  and  tactics  development  for  air  weapon  controllers,  and  performs  op¬ 
erational  test  and  evaluation  of  strategic  air  defense  systems.  TAC  also  supports  the  Pacific 
and  European  command’s  exercises  and  operations.  TAC’s  role  is  relevant  to  SPD  because  it 
must  utilize  SPD  to  carry  out  its  mission  to  perform  tactical  fighter,  reconnaissance,  com¬ 
mand,  and  control,  and  electronic  combat  operations  during  worldwide  contingencies;  and 
because  of  its  relevant  role  in  combat  training.  TAC  has  a  similar  organizational  structure  to 
SAC  and  MAC.  The  XR,  LG,  DO  and  SC  organizations  make  up  TAC’s  SPD  organizational 
environment. 
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An  example  of  a  TAC  MCCR  software  maintenance  program  exists  within  the  LG  division. 
The  Air  Force  Engineering  and  Technical  Services  (AFETS)  program  maintains  a  worldwide 
program  for  TAC,  PAC  AF,  AAC  and  USAFE  and  resides  within  LG.  AFET’s  software  main¬ 
tenance  role  and  environment  is  summarized  below: 

•  AFETS  is  responsible  for  the  development,  monitoring,  and  implementation 
of  maintenance  support  programs  for  mission  changes  to  OFP  software. 

•  AFETS  does  not  currently  have  access  to  source  code  and  other  relevant  docu¬ 
mentation.  It  also  does  not  have  any  of  the  equipment  to  provide  full  mainte¬ 
nance  support,  and  there  are  no  initiatives  to  provide  any  in  the  future. 

•  The  ALC  is  still  very  much  involved  in  any  software  maintenance  performed  by 
TAC. 

TAC  does  provide  support  to  mission  software.  The  F-16  training  device  in  one  example. 
Originally,  the  training  devices  were  designed  as  a  generic  software  package.  TAC’s  responsi¬ 
bility  is  to  customize  the  software  package  by  “patching”  the  software.  The  ALC  manages 
the  overall  configuration  of  the  system  and  the  changes  to  the  software  code;  TAC  coordi¬ 
nates  these  changes  with  the  ALC. 

2.2.4.4  Air  Force  Space  Command  (AFSPACECOM) 

AFSPACECOM,  headquartered  at  Peterson  AFB,  CO,  is  responsible  for  organizing,  train¬ 
ing,  equipping  and  operating  forces  in  support  of  strategic  aerospace  defense,  space  control 
and  operations.  As  part  of  its  mission  AFSPACECOM  is  very  involved  with  developing  and 
maintaining  MCCR  software.  Unlike  TAC,  MAC  and  SAC  their  organization  is  not  sup¬ 
ported  by  AFCC.  The  Space  and  Warning  Systems  Center  (SWSC)  is  a  unit  within  AFSPACE¬ 
COM,  responsible  for  the  maintenance,  modification,  and  selected  development  of  the  soft¬ 
ware  intensive  command  and  control  systems  that  are  utilized  by  North  American  Aerospace 
Defense  Command  (NORAD)  and  AFSPACECOM. 

The  AFSPACECOM  supports  mainly  OFP  systems.  The  software  modification  performed 
by  AFSPACECOM  impacts  approximately  three  to  six  percent  of  the  code  for  stable  systems 
and  up  to  ten  percent  on  less  stable  systems.  AFSPACECOM  is  maintaining  approximately 
thirty  million  lines  of  code  and  is  planning  to  maintain  an  additional  thirty  million  lines  of 
code. 

2.2.4.5  Pacific  Air  Forces  (PACAF) 

PACAF  plans,  conducts,  and  coordinates  offensive  and  defensive  air  operations  in  an  area 
extending  from  the  west  coast  of  the  Americas  to  the  East  Coast  of  Africa  and  from  the  Arctic 
to  the  Antarctic.  HQ  PACAF  is  located  at  Hickam  AFB,  HI.  Introduction  of  newer  weapon 
systems  will  maximize  the  effectiveness  of  PACAF’s  widely  dispersed  forces. 

2.2.4.6  United  States  Air  Forces  in  Europe  (USAFE) 

USAFE.  headquartered  at  Ramstein  AB,  West  Germany,  is  the  air  component  of  the  U.S. 
European  Commands.  The  USAFE  executes  its  mission  with  the  support  of  such  weapon 
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systems  as  the  F-16  C/D,  F-15s,  F-lllAs,  and  F-111F.  However,  like  PACAF  and  AAC 
USAFE  is  supported  by  other  MAJCOM  software  maintenance  programs,  i.e  AFETS. 

2.2.4.1  Alaskan  Air  Command  (AAC) 

AAC,  headquartered  at  Elmendorf  AFB,  Alaska,  provides,  trains,  and  equips  a  tactical  Air 
Force  to  protect  the  United  States.  The  importance  of  Alaskan-based  forces  is  apparent,  giv¬ 
en  their  strategic  location  in  relation  to  potential  enemies  as  well  as  allies.  The  AAC  Com¬ 
mander  also  serves  as  Commander  for  the  Alaskan  NORAD  region.  AAC  primarily  carries 
out  its  function  of  being  an  Operational  Command.  The  AAC  is  supported  by  TAC’s  AFETS 
program. 

2.2.5  Other  Commands,  Centers,  Agencies  and  Working  Groups 

There  are  other  Air  Force  agencies,  commands  and  working  groups  who  have  responsibilities 
for  weapon  systems  and  MCCR.  These  agencies,  commands,  and  working  groups  are  de¬ 
scribed  in  Sections  2.2.5. 1  through  2.2.5.10. 

2.2.5.1  Air  Training  Command  (ATC) 

ATC,  headquartered  at  Randolph  AFB,  TX,  is  dedicated  to  cost-effective,  mission-oriented 
flight  training.  The  latest  advances  in  technology  are  being  implemented  by  ATC  using  Com¬ 
puter-Assisted  Instruction  (CAI)  and  Advance  Training  Systems.  The  training  is  mission-spe¬ 
cific  with  pilot  training  tailored  to  operational  aircraft.  ATC  provides  formal  training  for  soft¬ 
ware  maintenance  personnel,  operations,  and  computer  courses  in  software  languages. 
MCCR  training  functions  are  dispersed  across  different  divisions  within  the  Command.  In 
most  cases,  weapon  system  training  is  provided  by  the  contractor  who  developed  the  system. 
However,  at  times  ATC  is  tasked  to  provide  formal  training  for  the  personnel  who  will  be 
operating  and  maintaining  MCCR  software. 

2.2.5.2  Air  Force  Communications  Command  (AFCC) 

AFCC,  headquartered  at  Scott  AFB,  IL,  is  responsible  for  the  acquisition,  engineering,  in¬ 
stallation,  operation  and  maintenance  of  telephone  systems,  base  communication  centers, 
computer  facilities,  radio  and  satellite  stations,  and  air  traffic  control.  AFCC  is  also  responsi¬ 
ble  for  improving  software  development  and  acquisition  procedures.  Virtually  every  space 
system  relies  on  software;  AFCC  provides  support  for  these  space  systems.  The  AFCC’s  Stan¬ 
dard  Systems  Center  (SSC)  at  Gunter  AFB,  AL,  is  a  model  standard  systems  software  acquisi¬ 
tion  agent  and  life-cycle  manager.  The  center  maintains  and  develops  software  under  the 
AFR  700  and  AFR  800  series.  However,  the  programs  that  are  developed  within  the  SSC, 
under  DOD-STD-2167A  are  not  embedded  computer  systems  but  information  systems. 

2.2.5.3  Electronic  Security  Command  (ESC) 

ESC,  headquartered  at  Kelly  AFB,  TX,  provides  electronic  combat  support  and  operations 
security  support  to  Air  Force  units.  The  Command  provides  technical  assistance  to  the  devel- 
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opment  of  Air  Force  EW  and  Command,  Control,  and  Communications-Countermeasures 
(C3CM)  systems.  ESC  functions  as  a  consultant  for  operators  and  acquisition  commands;  it 
dees  not  modify  or  develop  software  but  analyzes  systems  to  advise  operators  and  acquisition 
personnel  on  modifications  or  acquisitions  that  they  should  make.  An  example  of  a  current 
ESC  effort  is  called  “EW  flagging”.  The  EW  flagging  system  determines  the  systems  perform¬ 
ance  and  how  the  operator  should  respond  to  its  performance.  ESC  is  required  to  have  access 
to  the  EW  system’s  SPD  to  provide  the  required  expertise. 

2.2.5.4  Air  Force  Operational  Test  and  Evaluation  Center  (AFOTEC) 

AFOTEC  is  located  at  Kirtland  AFB,  NM,  with  an  additional  five  detachments  at  Eglin  AFB, 
FL;  Nellis  AFB,  NV;  Edwards  AFB,  CA;  Colorado  Springs,  CO;  and  Kapaun  Barracks  West 
Germany.  AFOTEC  is  designated  a  separate  operating  agency  and  is  responsible  for  manag¬ 
ing  the  operational  testing  of  all  major  systems  being  developed  and  acquired  by  the  Air 
Force.  Its  primary  purpose  is  to  reduce  risk  in  the  acquisition  process  by  evaluating  system 
performance  in  a  realistic  environment.  AFOTEC  assigns  test  teams  to  designated  sites  to 
collect,  analyze,  and  evaluate  the  data;  and  to  prepare  formal  reports.  The  center  provides 
operational  test  and  evaluation  data  to  the  Chief  of  Staff,  Secretary  of  the  Air  Force,  and  the 
Secretary  of  Defense  for  use  in  making  system  acquisition  decisions.  The  center  also  recom¬ 
mends  implementation,  test,  and  evaluation  policy;  monitors  major  commands  when  they 
conduct  tests,  and  evaluates  processes  for  MCCR  software  being  acquired  or  developed. 
AFOTEC  activities  cover  the  spectrum  of  Air  Force  missions.  Most  of  the  personnel  in  the 
AFOTEC  test  teams  are  from  the  Major  Commands.  These  personnel  provide  current  op¬ 
erational  experience  to  ensure  that  the  evaluation  reflect  the  needs  of  the  system  users. 

2.2.5.5  Computer  Resources  Working  Group  (CRWG) 

The  CRWG  is  established  for  each  weapon  system  program  during  early  acquisition  and  en¬ 
sures  intercommand  involvement.  The  group  includes  representatives  from  all  commands. 
One  of  the  primary  responsibilities  of  the  CRWG  is  to  update  the  CRLCMP.  This  plan  identi¬ 
fies  the  organizational  relationships  and  responsibilities  for  management  and  technical  per¬ 
sonnel  and  for  support  of  all  MCCR  for  any  program.  CRWG  chairmanship  changes  at 
PMRT,  switching  from  the  SPO  or  SPO  personnel  to  the  Supporting  Command  SPM. 

2.2.5.6  Configuration  Control  Board  (CCB) 

The  CCB  has  primary  responsibility  and  authority  for  the  overall  configuration  management 
of  each  system.  In  situations  where  the  software  support  is  split  among  Commands,  the  CCB 
controls  the  interfaces  between  mission  and  system  software,  and  is  responsible  for  overall 
system  integrity.  The  CCB  is  chaired  by  the  SPO  in  AFSC  prior  to  PMRT  and  at  PMRT  is 
chaired  by  the  SPM. 

2.2.5.7  Software  Configuration  Control  Sub-Board  (SCCSB) 

The  SCCSBs  are  established  to  maintain  CSCIs  within  the  weapon  system.  Their  responsibi¬ 
lities  are  the  same  as  the  CCB,  except  that  they  maintain  indi  vidual  CSCIs  or  groups  of  CSCIs, 
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as  opposed  to  the  overall  system.  The  SCCSB,  as  well  as  the  CCB,  depends  largely  on  SPD  to 
maintain  systems  integrity,  through  strong  configuration  management. 

2.2.5.8  Air  University  (AU) 

AU  Headquarters  is  located  at  Maxwell  AFB,  AL.  AU  is  responsible  for  providing  profes¬ 
sional  military  education  and  degree-granting  programs  for  continuing  education.  The  Air 
Force  Institute  of  Technology  ( AFIT)  located  at  Wright  Patierson  AFB,  OH  is  an  AU  school 
that  teaches  a  course  in  MCCR  software  management.  The  course  is  entitled  “Mission  Criti¬ 
cal  Computer  Software  Management”  and  is  taught  in  the  school  of  Systems  and  Logistics  as 
part  of  the  Department  of  Systems  Acquisition  Management  curriculum.  AU  offers  many 
related  graduate  courses  in  many  facets  of  software  management  (i.e  software  cost  estimation 
and  software  project  management). 

2.2.5.9  Air  Force  Reserves  (AFRES) 

AFRES  is  a  separate  operating  agency  that  provides  trained  units  and  qualified  personnel  for 
active  duty  in  times  of  emergency  and  supports  the  Air  Force  mission  requirements  as  a  by¬ 
product  of  training  for  peacetime  missions.  A  larger  portion  of  the  Air  Force’s  total  airlift 
capability  is  provided  by  AFRES  units  and  their  crews. 

2.2.5.10  Air  National  Guard  (ANG) 

The  ANG  federal  mission  is  to  provide  units  of  equipped  and  trained  personnel  for  prompt 
mobilization.  ANG  units  are  assigned  to  ten  Major  Commands  of  the  Air  Force:  AFCC, 
AFSC,  ESC,  MAC,  PAC AF,  TAC,  SAC,  AAC,  ATC,  and  USAFE.  All  these  Commands  use 
or  contribute  to  the  development  or  maintenance  of  MCCR  weapon  systems. 
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2.3  VARIABLES  THAT  AFFECT  THE  ORGANIZATIONAL  ENVIRONMENT 


There  are  two  variables  affecting  the  organizational  environment:  the  MCCR  software  cate¬ 
gory  and  the  software  life  cycle  functions. 

2.3.1  MCCR  Software  Categories 

The  first  variable  affecting  the  organizational  environment  is  the  MCCR  software  category. 
The  scope  of  the  SPD  study  is  defined  in  terms  of  the  MCCR  software  categories  that  were 
originally  defined  in  AFLCR-800-21.  There  are  nine  software  categories  within  the  MCCR 
umbrella,  five  of  the  nine  are  included  in  this  study:  OFP,  EW,  C-E,  ATD,  and  ATE.  These 
software  categories  are  defined  in  TABLE  2-1. 

TABLE  2-1.  DEFINITION  OF  MCCR  SOFTWARE  CATEGORIES 

OPERATIONAL  FLIGHT  PROGRAM  (OFP) 

The  software  used  to  execute  in-flight  computers  and  perform  functions  integral  to 
the  airborne  system.  This  software  support  is  the  responsibility  of  the  SPM. 

ELECTRONIC  WARFARE  (EW) 

The  software  used  to  execute  computers  for  weapon  systems  that  use  electromagnetic 
energy. 

COMMUNICATION  -  ELECTRONICS  (C-E) 

The  software  used  to  support  command,  control,  and  communications  functions;  to  pro¬ 
vide  surveillance  and  warning  to  Air  Traffic  Control;  and  to  provide  meteorological  sup¬ 
port. 

AIRCREW  TRAINING  DEVICES  (ATD) 

Software  used  to  execute  trainer  computers;  these  simulate  mission  training  functions  to 
support  primary  weapon  systems. 

AUTOMATIC  TEST  EQUIPMENT  (ATE) 

Software  used  to  test  missile  or  aircraft  units  and  to  execute  and  maintain  test  programs. 

Matrix  analysis  is  used  to  represent  the  different  organizations  that  participate  in  developing 
and  acquiring  the  different  categories  of  software.  There  are  four  matrices: 

•  ALC  responsibility  by  MCCR  software  category, 

•  ALC  responsibility  by  End  Items  and  Weapon  Systems, 

•  Maintenance  support  level  by  ALC  and  MCCR  software  category,  and 

•  Product  Division  responsibility  by  MCCR  software  category. 
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The  MCCR  software  categories,  listed  in  TABLE  2-1  impact  the  SPD  organizational  support 
environment.  Each  weapon  system  establishes  a  CRLCMP  that  dictates  which  organizations 
have  support  responsibilities.  In  addition,  a  support  facility  is  established  at  each  ALC  re¬ 
sponsible  for  the  weapon  system  or  end  item.  Even  though  these  two  factors  (CRLCMP  and  a 
support  facility)  should  remain  constant  for  every  category  of  weapon  system,  the  organiza¬ 
tions  involved  in  acquiring  or  supporting  the  weapon  system’s  MCCR  software  category  may 
differ. 

The  impact  of  MCCR  software  category  on  the  SPD  Organizational  environment  can  be  ana¬ 
lyzed  for  maintenance  support.  There  are  four  types  of  maintenance  support  for  weapon  sys¬ 
tems  software:  modifying,  corrective,  adaptive,  and  perfective.  TABLE  2-2  defines  these  sup¬ 
port  types  and  estimates  the  percentage  of  support  provided  by  the  five  ALCs. 

TABLE  2-2.  TYPES  AND  PERCENT  OF  MAINTENANCE  SUPPORT  AT  ALC 


TYPES  OF  SUPPORT 

PERCENT  OF  SUPPORT* 

Modifying 

Performed  to  incorporate  approved  new  or  modified 
mission  requirements 

40% 

Corrective 

Performed  to  identify  and  correct  software,  perform¬ 
ance  and  implementation  failures. 

17% 

Adaptive 

Performed  to  adapt  software  to  system  changes  in  the 
data  requirements  or  the  hardware/software  technology 
base. 

26% 

Perfective 

Performed  to  enhance  performance,  improve  cost 
effectiveness,  improve  processing  efficiency,  or  improve 
maintainability. 

17% 

*  Source:  Software  Workshop  conducted  by  Project  Bold  Stroke,  8/89 

ALC  RESPONSIBILITY  BY  MCCR  SOFTWARE  CATEGORY 

To  clarify  software  support  responsibilities  the  following  matrices  divide  the  MCCR  software 
into  the  five  SPD  categories:  OFP,  EW,  C-E,  ATD  and  ATE.  Not  all  organizations  support  all 
five  categories.  The  ALCs  that  are  responsible  for  providing  maintenance  support  for  each 
category  of  software  are  listed  in  TABLE  2-3.  The  rows  represent  the  five  MCCR  software 
categories;  the  columns  represent  the  five  ALCs  within  AFLC  that  are  responsible  for  provid¬ 
ing  maintenance  support  for  MCCR  software  category.  The  intersecting  cells  are  blank  or  are 
marked  with  an  to  indicate  that  the  ALC  maintains  the  MCCR  software  category.  Deci¬ 
sions  for  which  ALC  will  support  a  weapon  system  are  made  on  a  case  by  case  basis. 
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TABLE  2-3.  ALC  RESPONSIBILITY:  BY  MCCR  SOFTWARE  CATEGORY 


ALC 

mccrn. 
Category  \ 

OO-ALC 

OC-ALC 

SA-ALC 

SM-ALC 

WR-ALC 

OFP 

♦ 

♦ 

♦ 

♦ 

♦ 

EW 

♦ 

♦ 

♦ 

C-E 

♦ 

♦ 

♦ 

♦ 

ATD 

♦ 

♦ 

ATE 

♦ 

♦ 

♦ 

♦ 

♦ 

ALCs  have  established  expertise  in  specific  MCCR  categories  and  therefore  weapon  systems 
are  assigned  to  ALCs  that  have  experience  in  the  MCCR  category.  Currently,  all  ALCs  sup¬ 
port  OFP  and  ATE  software.  ATE  software,  according  to  the  RAND  study,  requires  more 
personnel  resources  than  any  other  category  of  software.  The  majority  of  C-E  software  is 
supported  at  OO- ALC,  OC-ALC  and  WR-ALC.  However,  the  Using  Command  sometimes 
share  the  software  support  responsibilities  in  that  category.  EW  software  is  supported  by 
three  of  the  ALCs:  OO-ALC,  WR-ALC  (supports  airborne  software),  and  SM-ALC  (sup¬ 
ports  ground-based  software).  ATD  software  is  primarily  supported  by  contractor  personnel 
however,  OO-ALC  has  Item  Manager  (IM)  responsibility  for  ATD  software  and  has  some 
approval  authority  for  software  changes  performed  at  the  operational  facilities  by  the  con¬ 
tractors.  WR-ALC  also  provides  support  for  ATD  software. 

TABLE  2-3  is  a  general  view  matching  ALC  support  with  each  MCCR  category  of  software. 
In  contrast,  TABLE  2-4  is  more  specific  in  that  it  identifies  the  specific  weapon  system  and 
end  items  within  each  category  of  MCCR  software  that  are  supported  at  the  ALCs.  The  data 
included  in  the  matrix  is  generated  from  previous  studies  (i.e  PDD  Current  Environment  Re¬ 
port f,  Ferens  and  RAND)  and  also  from  ALC  site  visits.  The  matrix  gives  an  overall  perspec¬ 
tive  on  the  weapon  systems  and  end  items  (broken  down  by  MCCR  software  category)  that 
each  ALC  must  support.  The  rows  represent  the  five  MCCR  software  categories;  the  col¬ 
umns  represent  the  five  ALCs.  The  row  column  intersecting  cells  identify  the  weapon  systems 
or  end  items  supported. 

FIGURE  2-11  further  demonstrates  the  impact  of  the  MCCR  software  category  on  mainte¬ 
nance  support  across  all  ALCs.  Maintenance  support  includes  all  four  types  of  support:  Mo¬ 
difying,  Adaptive,  Corrective,  and  Perfective.  The  3-D  perspective  is  significant  because  it 
allows  one  to  examine  simultaneously  three  factors:  ALC,  level  of  maintenance  support,  and 
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TABLE  2-4.  ALC  RESPONSIBILITY  BY  END  ITEMS  AND  WEAPON  SYSTEMS 
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software  category.  The  graph  quantitatively  demonstrates  the  distribution  of  maintenance 
support  for  MCCR  software  categories  across  the  SPD  ALC  environment.  It  also  illustrates 
the  percentage  of  support  provided  by  the  individual  ALC  for  each  software  category.  ATE 
and  OFP  MCCR  software  categories  are  supported  by  all  ALCs  and  require  the  most  mainte¬ 
nance  support. 


FIGURE  2-11.  LEVEL  OF  MAINTENANCE  SUPPORT  PROVIDED  BY  ALCs: 

BY  MCCR  CATEGORY 


PRODUCT  DIVISIONS  BY  MCCR  SOFTWARE  CATEGORY 

Matrix  analysis  is  used  to  represent  the  different  organizations  that  participate  in  developing 
and  acquiring  the  different  categories  of  software.  In  TABLE  2-5  the  rows  represent  the  five 
MCCR  software  categories;  the  columns  represent  the  six  Product  Divisions,  within  the 
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AFSC  that  are  responsible  for  implementing  MCCR  software.  The  intersecting  cells  marked 
with  an  “♦  ”  indicate  that  the  Product  Division  acquires  the  MCCR  software  category. 

TABLE  2-5.  DEVELOPMENT  AND  ACQUISITION  OF  MCCR  SOFTWARE: 

BY  PRODUCT  DIVISION 


N.  Product 
N.  Div. 
MCCR  \ 
Category  \ 

ASD 

MSD 

BSD 

ESD 

SSD 

HSD 

OFP 

♦ 

♦ 

♦ 

♦ 

♦ 

EW 

♦ 

♦ 

♦ 

♦ 

♦ 

C-E 

♦ 

♦ 

♦ 

♦ 

♦ 

ATD 

♦ 

♦ 

♦ 

ATE 

♦ 

♦ 

♦ 

♦ 

♦ 

2.3.1.1  Life  Cycle  Function 

A  second  variable  that  impacts  the  SPD  organizational  environment  is  the  system  software 
life  cycle  process.  Often  more  than  one  organization  is  responsible  for  each  function  through¬ 
out  the  software  life  cycle.  The  life  cycle  functions  (summarized  in  Section  3:  IDEF  Diagrams, 
and  described  in  more  detail  in  Appendix  B)  are  cross  referenced  with  the  organizations  that 
perform  each  function.  TABLE  2-6  illustrates  the  organizations  that  are  included  in  the 
IDEFs.  The  rows  represent  the  organizations  that  are  involved  in  carrying  out  the  life-cycle 
function.  The  columns  represent  the  life-cycle  functions  performed.  The  intersecting  cells 
marked  with  an  “♦  ”  indicate  that  the  respective  organization  performs  the  function.  The 
organizations  and  functions  are  consistent  with  those  depicted  in  the  IDEFs. 

2.4  Conclusions 

An  understanding  of  the  responsibilities  of  the  Air  Force  organizations  is  essential  to  under¬ 
stand  the  MCCR  software  life  cycle  and  the  SPD  environment.  The  organizational  asses¬ 
sment  determined  that  the  ALC  Materiel  Management  (MM)  and  Maintenance  (M  A)  Direc¬ 
torates  are  the  major  users  of  SPD,  but  that  the  Using  Commands  also  use  SPD  to  support 
software  maintenance  and  modifications.  The  assignment  also  determined  that  the  AFSC 
Product  Division/SPO  is  responsible  for  most  SPD  acquisition  and  reviews. 


2-33 


CONTRACTOR 


2-34 


Examination  of  the  current  SPD  organizational  environment  further  revealed: 

•  AFLC  assumes  management  responsibility  for  weapon  system  software  mid¬ 
way  through  the  life  cycle,  at  PMRT.  The  software  modification  role  performed 
by  AFLC  is  a  function  that  requires  a  full  life  cycle  perspective.  A  large  soft¬ 
ware  modification  usually  undergoes  requirements  analysis,  design,  develop¬ 
ment,  test  and  installation;  in  other  words,  virtually  a  full  life  cycle,  just  like  the 
original  software  development. 

•  The  software  functions  of  the  Product  Divisions  and  ALCs  vary,  according  to 
the  categories  of  MCCR  software  for  which  they  are  responsible.  Some  Prod¬ 
uct  Divisions  develop  specific  MCCR  software  categories,  whereas  some  ALCs 
support  specific  MCCR  software  categories.  In  addition,  the  software  category 
seems  to  dictate  the  amount  of  maintenance  support  required.  Based  on 
FIGURE  2-11,  ATE  and  OFP  software  categories  require  the  most  ALC  sup¬ 
port. 

•  PACER  STRIDE  redefined  the  roles  of  software  maintenance  within  the 
ALCs.  Although  the  changes  are  not  yet  documented  in  regulations,  most  of 
the  maintenance  responsibilities  previously  tasked  to  MM  have  been  trans¬ 
ferred  to  MA 

•  Organizations  that  are  most  involved  with  SPD  management  at  the  ALCs  in¬ 
clude  the  Operations  and  Support  Branch  (MMEO)  and  the  Software  Support 
Division  (MAS)  or  their  equivalents. 

•  The  five  support  concepts  outlined  in  AFR  800-14  identify  the  lead  and  sup¬ 
port  roles  when  more  than  one  Command  i  maintaining  the  software.  The 
current  trend  is  for  Using  Commands  to  have  i;  ct  eased  maintenance  responsi¬ 
bilities  for  selected  MCCR  mission  software. 

•  Many  intercommand  organizations  and  working  groups  are  formed  during  the 
software  life  cycle  process,  so  that  there  is  a  clear  understanding  of  the  develop¬ 
ment,  test,  and  support  requirements  and  responsibilities.  Examples  of  inter¬ 
command  organizations  are  CCB,  SCCSB,  and  CRWG. 
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SECTION  3:  IDEE  DIAGRAMS 


3.1  IDEF  IN  PERSPECTIVE 

IDEF  was  created  by  the  USAF  Integrated  Computer-Aided  Manufacturing  (ICAM)  pro¬ 
gram.  IDEF  originated  in  the  1970s  with  a  methodology  known  as  Structured  Analysis  & 
Design  Technique  (SADT).  IDEF  added  features  turned  the  SADT  methodology  into  a 
standard  language  that  describes  the  decisions,  actions,  and  activities  that  make  up  complex 
orgamzationai  environments. 

IDEF  is  required  on  DOD  manufacturing  programs.  It  is  the  standard  approach  for  defining 
ar.d  understanding  systems  requirements. 

3.2  UNDERSTANDING  IDEF 

IDEF  is  a  structured  methodology  that  uses  rules  for  functional  modeling  and  decomposi¬ 
tion,  The  IDEF  diagram  uses  boxes  to  represent  functions,  operations  or  activities.  Input 
arrows  allow  each  activity  to  be  analyzed  in  terms  of  Inputs,  Controls,  Outputs  and  Mecha¬ 
nisms  (ICOMs)  and  interrelationships  among  activities.  The  term  IDEF  is  an  acronym  for 
‘T’CAM  “DEF”inition.  The  ICOMs  indicate  the  constraints  on  an  activity  and  the  informa¬ 
tion  and  materials  that  are  used  in  or  produced  by  the  activity  (see  FIGURE  3-1).  The 
process  name  appears  in  each  box.  Information  flow  between  activities  is  represented  by 
arrows  that  interconnect  the  activity  boxes. 

CONTROLS  — 

factors  that  constrain  the  function  (i.e. ,  regulations,  pamphlets,  etc.) 


INPUTS 

consumed  or  transformed 
in  the  function 


MECHANISMS 

systems,  organizations,  people,  or  equipment 
that  support  or  perform  the  function 

FIGURE  3-1.  IDEE  METHODOLOGY  APPROACH 

IDEE  models  work  on  a  hierarchical  structure  in  which  functions  are  decomposed  into  sub- 
functions,  each  of  those  sub-functions  is  broken  down  into  its  respective  sub-functions. 
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This  decomposition  continues  until  the  needed  level  of  detail  is  reached.  FIGURE  3-2  uses 
the  IDEF  model  structure  to  illustrate  a  series  of  four  diagrams  and  their  interrelationships. 


Every  component  may  be  decomposed  in  another  diagram 
Every  diagram  shows  the  "inside"  of  a  box  on  a  parent  diagram 


FIGURE  3-2.  IDEF  MODEL  STRUCTURE 
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3.3  USE  OF  IDEF 


IDEF  methodology  is  primarily  used  for  understanding  functions  that  are  carried  out  and  the 
relationships  between  the  functions  within  the  current  environment.  IDEF  can  then  be  used 
to  depict  the  model  for  future  operations.  IDEF  methodology  is  frequently  used  in  Air 
Force-related  projects. 

IDEF  has  been  adopted  to  model  the  software  development  and  maintenance  processes 
because  of  its  similarity  to  the  manufacturing  process.  To  control  complexity,  a  given  mod¬ 
ule  or  CSU  should  ideally  consist  of  between  100-200  lines  of  code  which  process  a  single 
input  to  produce  a  single  output.  These  modules  are  aggregated  into  CSCs  and  ultimately 
into  CSCIs.  Each  CSU  module  has  controls  or  constraints  in  terms  of  timing,  accuracy, 
dependencies,  etc.  The  mechanisms  by  which  each  module  performs  its  processing  task  are 
the  compilers,  operating  systems,  languages  and  computer  hardware. 

The  node  tree  diagram  shown  in  FIGURE  3-3  provides  a  “road  map”  to  the  SPD  environ¬ 
ment.  The  node  tree  does  not  illustrate  the  flow  of  information,  but  it  does  show  the  break¬ 
down  of  functions  from  the  most  general  (level  0  diagram)  down  to  the  most  detailed  sub¬ 
function  (level  4  diagrams).  The  node  tree  provides  a  reference  point  for  understanding  the 
activities  and  decomposition  represented  in  the  IDEF  diagrams. 

3.4  DESIGN,  DEVELOP  AND  MANAGE  WEAPON  SYSTEM  SOFTWARE  -  NODE  AO 


Node  AO  (FIGURE  3-4)  provides  the  context  and  a  high  level  overview  of  the  entire  SPD 
process.  Node  AO  is  comprised  of  two  major  activities:  the  acquisition  (Node  Al)  and  the 
deployment/management  (Node  A2).  The  acquisition  node  is  responsible  for  creating  the 
majority  of  software  products.  These  products  are  needed  throughout  the  PDSS  cycle.  The 
system  must  adjust  to  changes  in  the  mission,  so  that  “software  maintenance”  is  predominant¬ 
ly  software  development. 

This  section  presents  levels  0  and  1  IDEF  diagrams  only.  The  entire  set,  describing  the  cur¬ 
rent  software  environment  from  levels  0  to  4,  is  contained  in  Appendix  B  of  this  document. 


3.4.1  Acquire  Weapon  System  Software  -  Box  Al 


This  activity  comprises  all  development  activity  up  to  and  including  PMRT.  The  acquisition  is 
decomposed  into  four  phases.  It  is  not  until  FSD  that  software  actually  is  developed.  Howev¬ 
er,  the  system  concept  will  have  an  effect  on  what  software  will  be  required.  Node  Al 
(FIGURE  3-5)  illustrates  this  activity. 


INPUTS: 

OUTPUTS: 

CONTROLS: 


MECHANISMS. 


Mission  Requirements,  PMD,  MENS,  SON,  PMP,  SEMP,  CMP,  SOC 
Tested  CSCIs,  SPD,  CRLCMP,  Configuration  Data,  CRISP,  O/S  CMP 
DODD  5012.19,  AFR  65-3,  DOD-STD-480A,  AFSCP  800-7, 
MIL-STD-493A,  AFR  800-4,  DODD  5000.31,  AFR  700-9, 

DODD  5000.3,  AFR  80-14,  AFR  800-19,  DOD-STD-2167A, 
MIL-STD-2168 

Product  Divisions,  Using  Commands,  ALCs,  Contractors 
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Level  o  Design,  Develop  &  Manage 

Weapon  System  Software 
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FIGURE  3-3  SPD  IDEF  NODE  TREE 


3.4.2  Deploy  &  Manage  Weapon  System  Software  -  Box  A2 

This  node  encompasses  the  life  cycle  of  the  software  Post-PMRT.  It  consists  of  two  major 
activities;  system  deployment  and  system  support.  System  deployment  is  the  primary  activity 
outlined  for  the  Using  Command.  Maintenance  of  the  system  and  the  ECS  software,  is  de¬ 
picted  in  node  A22  (see  Appendix  B).  Node  A2  (FIGURE  3-6)  illustrates  this  activity. 

INPUTS:  Block  Change  Cycle,  Tested  CSCIs,  SPD,  CRLCMP,  Configuration 

Data,  CRISP,  O/S  CMP 

OUTPUTS:  Mission/System  Capabilities 

CONTROLS:  AFLCR  800-21,  DODD  5010.12,  AFR  800-14,  AFR  310-1, 

DOD-STD-1467,  AFSCP  800-3 

MECHANISMS:  ALCs,  Using  Commands,  Support  Contractor 

3.5  IDEF  SUMMARY 

Through  developing  the  IDEF  diagrams,  five  major  pre-  and  post-production  support  appli¬ 
cations  of  SPD  were  identified.  For  virtually  all  of  these  applications,  the  continual  process  of 
SPD  review  prior  to  each  change  must  occur.  During  development,  SPD  review  serves  as  the 
primary  method  of  conveying  design  concepts  and  features.  Major  support  applications  are 
summarized  below. 

•  Software  Development  -  Throughout  the  development  cycle  described  in 
DOD-STD-2167A,  the  design  review  provides  the  Air  Force  with  the  op¬ 
portunity  to  verify  and  validate  the  requirements,  approach,  design,  and  fi¬ 
nal  product.  For  virtually  every  review  it  is  neccesary  to  develop  various 
products  that  will  make  up  the  set  of  SPD.  This  process  is  repeated  in  a 
series  of  audits  held  towards  the  end  of  the  acquisition  phase. 

•  Software  Maintenance  -  The  ALCs  and  Using  Commands  perform  a  variety 
of  tasks  related  to  software  maintenance:  compensating  for  a  design  flaw  or 
coding  error,  and/or  to  perfecting  the  software  to  maximize  the  use  of  avail¬ 
able  memory  space  and  improve  efficiency. 

•  Software  Modifications  -  The  ALCs  and  Using  Commands  perform  soft¬ 
ware  modifications  either  to  enhance  the  capability  of  the  software  or  to 
incorporate  a  change  in  mission.  Software  modification  tasks  mirror  soft¬ 
ware  development  cycle  tasks. 

•  Reverse  Engineering  of  Software  -  Some  ALCs  reverse  engineer  software 
code  to  develop  documentation  for  undocumented  code.  This  usually  takes 
place  when  the  system  life  is  expected  to  be  long  and  the  difficulties  of  sup¬ 
porting  the  code  outweigh  the  costs  of  reverse  engineering  the  code. 

•  Documentation  Updates  -  As  software  is  modified  and  maintained,  the  soft¬ 
ware  documentation  must  be  updated  so  that  a  current  baseline  is  available 
for  future  maintenance  and  modifications.  Furthermore,  this  documenta- 
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tion  will  support  the  development  of  the  TOs  needed  to  implement  changes 
in  the  weapon  system. 

In  developing  the  IDEF  diagrams,  reference  material  from  several  sources  were  used:  appli¬ 
cable  regulations,  pamphlets,  and  directives,  as  well  as  several  text  books  that  interpret  the 
use  of  these  regulatory  items.  These  sources  are  listed  in  Appendix  C  of  this  document.  It  was 
noted  that  differences  existed  between  the  various  reference  sources  as  to  when  design  re¬ 
views  should  take  place.  There  were  also  interpretive  differences  in  MIL-STD-1521B.  Each 
reference  assigns  a  different  degree  of  freedom  in  the  management  of  a  highly  structured  pro- 
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FIGURE  3-6.  DEPLOY  AND  MANAGE  WEAPON  SYSTEM  SOFTWARE 


SECTION  4:  FINDINGS 


4.1  INTRODUCTION 

This  section  identifies  some  of  the  major  issues  facing  the  Air  Force  today  in  software  devel¬ 
opment  and  support,  based  on  the  analysis  of  the  current  Air  Force  environment  for  those 
aspects  of  MCCR  relating  to  a  weapon  system.  The  findings  describe  areas  needing  improve¬ 
ment  and  will  be  researched  further  in  Phases  2  and  3  of  the  modular  planning  process  (see 
FIGURE  1-5). 

In  addition,  a  quantitative  description  of  the  volume  of  SPD  in  the  Air  Force  is  provided. 
With  this  information,  trends  in  the  growth  and  management  of  SPD  can  be  identified,  and 
reflected  in  the  technical  requirements  of  the  To-Be  Concept. 

4.2  SPD  DIMENSIONS 

This  section  presents  a  quantitative  view  of  current  SPD  within  the  Air  Force,  and  the  antici¬ 
pated  volume  of  SPD  that  can  be  expected  in  the  future.  The  data  to  support  this  view  was 
acquired  through  phone  surveys  of  the  SCCs  within  each  ALC,  and  through  the  SPD  Valida¬ 
tion  Package,  which  was  used  to  assess  current  Air  Force  SPD-related  functions  and  pro¬ 
cesses. 

The  Computer  Program  Identification  Number  (CPIN)  system  was  found  to  be  the  only  op¬ 
erational  software  tracking  and  identification  program  currently  implemented  within  the  Air 
Force  that  could  provide  hard,  quantifiable  sizing  estimates  related  to  SPD. 

4.2.1  CPIN  System 

CPINs  are  sight-recognizable  numbers  that  identify  software  items  or  their  associated  docu¬ 
mentation.  CPINs  are  part  of  the  MCCR  CSCI  CM  process  since  they  identify: 

•  General  category  of  the  CSCI, 

•  Major  function, 

•  Weapon  system  and  subsystem  in  which  the  CSCI  resides, 

•  Version, 

•  Whether  the  number  is  for  an  actual  item  or  associated  documentation,  and 

•  The  number  of  revisions  the  item  has  undergone. 

CPIN  management  is  coordinated  by  and  the  numbers  assigned  by  OC-ALC.  As  of  29  Janu¬ 
ary  1990.  the  CPIN  system  was  handling  66,147  CPINs.  It  is  generally  accepted  that  this  num¬ 
ber  may  be  broken  in  half  to  reflect  the  two  types  of  CPINs:  CSCIs  themselves  (Item  CPINs) 
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and  associated  documentation  packages  (Documentation  CPINs).  A  documentation  pack¬ 
age  consists  of  one  or  any  combination  of  the  following  pieces  of  documentation  that  support 
CSCI  items:  source  code,  DOD-STD-2167A  Data  Items,  TOs,  indexing  and  cross  referenc¬ 
ing  information.  The  estimated  number  of  documentation  CPINs  across  the  five  ALCs  is  ap¬ 
proximately  33,073. 

4.2.1.1  Characteristics 

The  quantity  of  documentation  assigned  to  each  CPIN  can  vary  dramatically  from  one  CSCI 
to  another.  Similarly,  the  average  number  of  pages  per  documentation  CPIN  can  vary  from 
one  ALC  to  another.  These  variations  can  be  ascribed  to  the  differences  in  complexity  of  the 
weapon  systems  at  the  various  ALCs.  For  example,  OC-ALC  averages  approximately  4100 
pages  per  documentation  CPIN  due  to  its  support  of  highly  complex  weapon  systems,  such  as 
the  B-1B.  In  contrast,  SA-ALC  averages  approximately  150  pages  to  support  mostly  trans¬ 
port  planes  and  tankers.  These  weapon  systems  are  far  less  software  intensive  than  the  B-1B. 
The  average  number  of  pages  per  documentation  CPIN  was  computed  for  each  ALC  by  divid¬ 
ing  the  total  pages  of  documentation  by  the  number  of  documentation  CPINs. 

4.2. 1.2  Trends 

TABLE  4-1  and  TABLE  4-2  illustrate  current  trends  in  software  documentation.  Even 
though  OC-ALC  has  the  fewest  number  of  CPINs  by  a  large  margin,  it  has  the  highest  aver¬ 
age  number  of  pages  per  documentation  CPIN,  and  approximately  4  million  more  pages  of 
documentation  than  the  other  four  ALCs  combined  (see  TABLE  4-3).  The  total  amount  of 
software  documentation  associated  with  MCCR  CSCIs  supported  by  the  five  ALCs  presently 
stands  at  approximately  20.6  million  pages.  OC-ALC  currently  supports  12.5  million  of  these 
pages,  or  60%  of  the  total. 

The  fact  that  OC-ALC  supports  the  majority  of  the  more  recent  embedded  CSCIs  within  the 
Air  Force  accounts  for  this  trend  in  increased  pagination.  OC-ALC  also  exemplifies  the 
growing  problems  associated  with  CM  of  CSCIs.  In  an  attempt  to  save  time  and  money  spent 
on  documentation  tasks  set  by  DOD-STD-2167  A  many  contractors  group  together  several 
items  into  one  CSCI.  This  allows  them  to  deliver  one  set  of  documentation  for  a  group  of 
software  items.  The  ALCs  must  then  decide  which  of  two  complex  and  troublesome  options 
to  implement:  break  up  the  CSCI  into  modules  and  assign  individual  CPINs,  or  attempt  to 
manage  a  large,  unmodular  CPIN  assigned  to  the  CSCI,  as  is.  In  many  cases,  several  CSCIs 
that  make  up  a  system  are  assigned  one  CPIN.  This  accounts  for  much  of  the  increased  pagi¬ 
nation  per  documentation  CPIN. 

Within  newer  weapon  systems,  this  trend  may  in  fact  help  CSCI  CM.  In  the  past,  many  systems 
had  no  support  documentation,  with  the  exception  of  the  source  code  listing.  Today,  a  large 
percentage  of  the  DOD-STD-2167A  Data  Items  are  purchased;  this  drives  up  both  the  in¬ 
crease  in  pages  per  CPIN  and  the  potential  system  supportability.  The  number  of  Data  Items 
procured  under  DOD-STD-2167A  has  risen  to  a  current  level  of  approximately  50%.  The 
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potential  exists  for  the  Air  Force  to  take  advantage  of  this  information  and  substantially  in¬ 
crease  system  supportability.  However,  due  to  the  lack  of  an  automated  SPD  capability,  60% 
of  software  modification  time  is  currently  devoted  to  the  retrieval  and  analysis  of  documenta¬ 
tion. 

TABLE  4-1.  CPIN  VOLUME  ACROSS  ALL  ALCs 
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TABLE  4-2.  AVERAGE  PAGES  PER  DOCUMENTATION  CPIN  BY  ALC 


CSCI  cross  referencing  and  indexing  are  functions  of  CM  which  currently  are  being  per¬ 
formed  more  often.  This  trend  may  translate  to  an  increase  in  pages  per  CPIN,  yet  be  looked 
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at  positively  in  that  it  enhances  overall  system  supportability.  However,  this  information  is 
only  useful  if  it  is  managed  properly  and  can  be  accessed  in  a  timely  manner. 

TABLE  4-3.  TOTAL  SPD  PAGES  ACROSS  ALCs 


4.2.2  SPD  Growth 

Based  on  interviews  with  several  ALCs,  overall  Air  Force  software  documentation  is  increas¬ 
ing  at  a  rate  of  approximately  25%  per  year.  This  percentage  is  expected  to  increase  further 
with  the  influx  of  new,  software  intensive  weapon  systems  within  the  next  ten  years.  For  exam¬ 
ple.  SM-ALC  SPD  levels  are  expected  to  increase  dramatically  with  the  acquisition  of  the 
Advanced  Tactical  Fighter  (ATF).  SA-ALC  SCC  personnel  currently  report  that  their  soft¬ 
ware  documentation  is  expanding  at  a  rate  of  35-50%  per  year.  OC-ALC  personnel  have 
reported  that  the  CPIN  system  is  assigning  new  numbers  at  a  rate  of  7%  ‘.i  year  and  this  rate 
is  expected  to  remain  constant.  These  trends  indicate  that  the  average  number  of  pages  of 
documentation  for  each  documentation  CPIN  at  the  various  ALCs  will  approach  the  level 
currently  seen  at  OC-ALC  (over  4000  pages/documentation  CPIN). 

As  seen  in  TABLE  4-4,  software  documentation  is  going  to  increase  exponentially  in  the  next 
ten  years,  yet  CSCIs  are  expected  to  continue  growing  at  a  7%  annual  rate  (reflected  by  CPIN 
assignments).  ALC  PDSS  organizations  nr y  encounter  resource  difficulties  managing  this 
tremendous  amount  of  documentation  that  will  support  future  CSCIs.  The  documentation 
levels  in  TABLE  4-4  are  based  on  a  25%  increase  rate  per  year  (based  on  Air  Force  projec¬ 
tions).  However,  newer  software- intensive  systems  are  likely  to  increase  this  rate  up  to  or 
above  the  current  SA-ALC  level  of  35-50%.  TABLE  4-4  therefore  represents  a  conserva¬ 
tive  view  of  software  documentation  growth. 
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4.2.3  C PIN  Summary 


Currently,  the  overall  Air  Force  level  of  pages  of  software  documentation  is  approximately 
600  pages  per  CPIN.  TABLE  4-4  shows  that  this  level  will  expand,  Air  Force-wide,  to  ap¬ 
proximately  2800  pages  per  CPIN  within  the  next  10  years. 

TABLE  4-4.  TRENDS  IN  TOTAL  CPINs  AND  SOFTWARE  DOCUMENTATION 


Using  the  present  growth  rate,  software  documentation  will  approach  approximately  180  mil¬ 
lion  pages  in  the  next  10  years.  Compared  to  the  current  level  of  approximately  20  million 
pages,  180  million  pages  translates  to  a  800%  increase.  These  data  need  to  be  produced  to 
support  and  manage  Air  Force  software.  The  current  SCC  infrastructure  may  not  be  ade¬ 
quate  to  manage  this  volume  of  data  unless  improved  techniques  are  used  for  automated  sup¬ 
port. 
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4.3  FINDINGS 

The  findings  are  summarized  below  and  discussed  further  in  Sections  4.3.1  through  4.3.11 

•  Software  CM  in  the  Air  Force  is  impeded  by  a  variety  of  factors  (e.g.,  lack  of 
documentation,  fragmentation  of  support  responsibility,  and  inadequate 
CM  systems),  which  in  turn  hinder  PDSS. 

•  Lack  of  detailed  documentation  for  software  support  is  a  major  problem 
that  slows  down  the  Air  Force’s  capability  to  maintain  and  modify  existing 
software  inventories. 

•  There  is  a  lack  of  CALS  standards  for  the  digital  receipt,  management,  and 
use  of  SPD. 

•  Logistics  resources  to  support  software  need  to  be  identified  during  the  ac¬ 
quisition  phase  either  through  DOD-STD-2167A  or  through  application 
of  the  LSA  process  to  software. 

•  Changes  to  software  most  often  require  a  TCTO  to  implement  the  software 
change. 

•  There  is  a  relationship  between  SPD  and  TOs.  Most  software  changes  re¬ 
quire  issuance  of  a  Time  Compliant  Technical  Order  (TCTO). 

•  The  role  of  AFLC  and  Using  Command  software  acquisition  and  support  is 
changing.  Whereas  in  the  past  lines  of  responsibility  were  clearly  estab¬ 
lished.  under  today’s  regulations,  these  roles  are  not  limited  to  specific  or 
singular  commands.  In  fact,  sharing  of  development  and  maintenance  is 
now  possible. 

•  The  ALCs  sometimes  act  as  the  Independent  Verification  and  Validation 
(IV&V)  agent,  either  performing  the  IV&V  directly  or  issuing  a  contract  to 
have  it  done.  This  is  an  effective  means  of  preparing  the  ALC  for  its  PDSS 
responsibility  and  can  lead  to  supportability  improvements  in  software  de¬ 
sign.  This  approach  should  be  used  more  widely. 

•  Software  developed  under  DOD-STD-2167A  still  represents  a  small  per¬ 
centage  of  AFLC  software  inventories;  this  is  due  to  a  large  inventory  that 
existed  prior  to  this  standard’s  implementation  and  to  short-term  incentives 
to  avoid  using  the  standard  on  selected  modification  programs. 

•  The  use  of  CAS F.  tools  is  minimal  in  Air  Force  software  support. 

•  Testing  issues  need  to  be  identified  early  in  the  software  life  cycle  to  ensure 
reliable  performance. 

•  Retention  and  continued  training  of  Air  Force  software  personnel  will  be 
critical  for  achieving  mission  readiness  and  productivity,  and  for  maximiz¬ 
ing  competition  in  PDSS  contracting. 
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4.3.1  Software  Configuration  Management 

There  is  insufficient  CM  in  software  system  development  and  software  support.  From  the 
validation  meetings,  it  was  determined  that  software  changes  were  generally  made  under  the 
CCB.  Updating  and  analyzing  potential  changes  in  documentation  and  related  SPD  became 
a  task  for  which  the  system  was  ill-defined  and  the  engineer  ill-prepared.  In  several  in¬ 
stances,  computer  hardware  resources  were  made  available,  yet  the  resources  did  not  exist  to 
evaluate  and  develop  changes  in  the  SPD.  FIGURE  4-1  breaks  down  CM  into  four  functions: 
Audit,  Status  Accounting,  Control,  and  Identification.  One  flaw  in  current  practices  is  the 
Status  Accounting  function.  Various  versions/configurations  of  code  and  documentation  are 
kept  in  a  software  development  library.  However,  this  may  not  be  called  out  as  a  deliverable. 
Consequently,  the  complete  development  history  of  a  software  system  is  not  available  to  turn 
over  to  AFLC  at  PMRT.  It  is  important  to  retain  versions  of  developing  software  for  future 
modification  purposes. 


FIGURE  4-1.  CONFIGURATION  MANAGEMENT 

So  specific  are  CSCIs  in  relation  to  the  mission  they  support  that  currently  software  is  tracked 
to  the  level  of  individual  aircraft  tail  numbers:  this  results  in  the  potential  for  unique  configu¬ 
rations  on  each  platform.  While  tracking  software  by  tail  number  in  itself  may  not  require 
dedicated  resources,  the  ability  to  effect  a  multiplicity  of  different  changes  over  several  series 
of  aircraft  requires  not  only  tracking  support,  but  analysis,  expertise,  and  intelligence  in  the 
implementation  of  such  changes. 

Since  the  Air  f  orce  frequently  has  automated  CM  performed  by  the  prime  contractor,  the  Air 
force  should  be  able  to  acquire  CM  baseline  information  and  to  implement  it  at  their  user 
support  facilities  and  maintenance  support  facilities.  Lack  of  ef  fective  CM  can  lead  to  infor¬ 
mal  CM  practices  by  software  engineers.  This  practice  is  characterized  by  islands  of  automa- 
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tion  and  conflicting,  uncontrolled  baseline  information.  A  similar  practice  was  also  cited  in 
the  PDD  Current  Environment  Report  in  which  engineers,  faced  with  inadequate  CM  support, 
maintained  unauthorized  drawing  stores  on  their  own. 

In  general,  there  is  a  lack  of  automated  tools  that  support  CM  in  the  Air  Force,  creating  an 
intensive  paper-bound  process.  For  instance,  the  IJSTS  Program  at  ESD  and  the  F-l  1 1  pro¬ 
gram  both  rely  heavily  on  a  manual  CM  process.  The  kind  of  software  CM  currently  per¬ 
formed  by  the  Air  Force  is  sometimes  fragmented  between  user  and  maintenance  organiza¬ 
tions;  this  makes  CM  ineffective.  The  1980  TRW  Study  of  ECS  Software  found  that  CM  of 
ATD  software  suffered  from  a  lack  of  communication  between  the  responsible  ALC  and  De¬ 
velopment  Engineering  Prototype  Site  (DEPS)  teams  at  each  user  location.  Frequently  the 
DEPS  teams  and  the  ALC  both  made  the  same  change,  or  the  DEPS  team  mads  a  change 
without  updating  the  documentation  (except  for  the  source  code)  and  without  notifying  the 
ALC. 

There  are  exceptions  to  ineffective  software  CM  in  the  .Air  Force.  The  AWACS  Program  has 
relied  on  the  Boeing  Corporation  to  provide  overall  CM.  Likewise,  several  programs  at  OO- 
ALC  report  effective  CM  through  their  support  contractors,  partly  due  to  the  use  of  the  prime 
contractor  as  the  support  contractor. 

The  need  for  a  comprehensive  CM  approach  is  not  limited  to  the  software  arena.  In  a  pre¬ 
vious  Air  Force  CALS  study  ( PDD  Current  Environment  Report ,  May  1989),  it  was  shown  that 
poor  CM  for  engineering  data  impacted  the  quality  of  support  for  the  weapon  system. 

In  a  much  broader  context,  future  weapon  systems  will  depend  on  a  much  higher  degree  of 
integration  to  support  such  new  operational  concepts  as  graceful  degradation.  CM  of  SPD 
needs  to  be  identified  and  the  SPD  and  PDD  CM  repositories  integrated.  It  is  only  when 
these  capabilities  exist  that  support  issues  can  recognize  the  multiplicity  in  both  hardware  and 
software  across  several  versions  of  the  platform. 

4.3.2  Adequacy  of  Documentation  for  Software  Support 

In  many  ways,  the  term  "software  maintenance"  is  a  misnomer  because  this  type  of  work  ac¬ 
tually  involves  a  significant  amount  of  software  development.  The  1989  BOLD  STROKE 
briefing  material  cites  an  OO-ALC/MMET  source  which  states  that  66%  of  the  changes  oc¬ 
curring  during  PDSS  are  dedicated  towards  new  development.  This  figure  is  broken  down 
into  40%  towards  new  capabilities  and  26%  for  adaptive  changes.  The  remaining  34%  is 
equally  distributed  between  corrective  and  perfective  improvements.  Since  software  mainte¬ 
nance  involves  changing  some  pieces  of  an  existing  structure  in  a  way  that  will  not  disturb  the 
other  pieces  of  the  structure,  a  complete  set  of  current  documentation  is  needed  that  fully 
describes  both  the  externals  and  internals  of  the  structure.  The  importance  of  documentation 
is  further  supported  by  a  recent  Journal  of  Air  Force  Logistics  article,  which  stated  that  of  the 
total  time  required  to  accomplish  software  maintenance,  60%  of  the  time  is  devoted  to  the 
retrieval  and  analysis  of  appropriate  SPD. 


4-8 


Documentation  must  be  emphasized  during  the  acquisition  process  to  avoid  the  costs  in¬ 
curred  in  maintaining  an  undocumented  product.  Unfortunately,  when  program  funds  are 
reduced,  documentation  can  be  one  of  the  first  deliverables  to  be  traded  away.  This  signifi¬ 
cantly  increases  long  term  life  cycle  costs.  In  most  cases,  documentation  is  baselined  once 
during  the  development  cycle  and  is  seldom  updated  to  reflect  coding  changes.  At  PMRT,  the 
source  code  and  supporting  documentation  are  often  inconsistent.  To  be  considered  com¬ 
plete,  documentation  must  describe  the  problem  that  the  software  is  trying  to  solve,  the  de¬ 
sign  choices  and  tradeoffs,  the  standards  and  specifications  used,  and  the  software  design. 
DOD-STD-2167A  addresses  most  of  these  needs,  but  falls  short  of  identifying  the  choices 
made  by  the  software  designer  during  the  acquisition  phase,  the  tradeoff  analyses  performed, 
and  the  trade-off  decisions.  This  information  can  be  critical  to  PDSS  functions. 

The  Air  Force  does  not  subject  software  documentation  to  the  same  rigorous  validation  and 
verification  process  used  for  TOs.  The  TO  validation  process  involves  Air  Force  maintenance 
personnel  in  live,  test-use  of  a  proposed  TO,  and  they  uncover  any  missing  maintenance  steps 
or  inadequate  descriptions  and  instructions.  Even  though  validating  software  documentation 
is  an  equally  complex  and  labor-intensive  process,  few  or  no  expert  systems  or  other  auto¬ 
mated  tools  are  currently  in  use  in  the  Air  Force  to  make  software  documentation  reviews 
more  effective  and  efficient.  In  addition,  software  documentation  validation  assumes  a  high 
level  of  technical  expertise.  Under  a  similarly  vigorous  process  for  software  documentation, 
the  documentation  would  be  validated  against  the  appropriate  standard,  such  as  DOD- 
STD-2167  A  prior  to  being  baselined.  The  documentation  would  then  be  verified  by  having 
government  software  support  personnel  use  it  to  perform  a  series  of  support  tasks. 

As  part  of  its  effort  to  obtain  sufficient  documentation  to  efficiently  and  effectively  perform 
PDSS  functions,  the  Air  Force  needs  to  be  certain  that  it  acquires  the  data  rights  to  software 
purchased.  This  issue  was  highlighted  in  ALD’ s  1989  Supportable  Software  Acquisition  Guide 
and  is  a  generic  problem  for  CALS;  without  data  rights  to  re-use  data  or  even  distribute  data 
to  a  new  contractor  for  modification  work,  there  is  limited  value  in  digitally  acquiring  techni¬ 
cal  information.  In  the  software  arena,  contractors  may  claim  proprietary  data  rights  to  pre¬ 
serve  their  position  for  PDSS  modification  contracts. 

Requirements  traceability  is  a  critical  capability  that  documentation  can  begin  to  provide. 
For  any  software  change  request,  the  Ar  Force  evaluates  the  potential  system  impact  and 
mission  impact.  These  impact  analyses  can  best  be  performed  by  tracing  requirements 
through  the  design  and  the  code.  Only  when  these  analyses  have  been  performed  can  the  Ar 
Force  adequately  judge  whether  or  not  to  proceed  with  the  proposed  software  change.  Good 
documentation  can  help  to  support  this  capability;  automated  CASE  tools  are  another  means 
(see  Section  4.3.9). 

So  critical  is  the  need  for  adequate  documentation  that  some  ALCs  have  initiated  the  process 
ot  developing  or  “reverse  engineering:”  the  SPD.  In  cases  where  PDSS  is  severely  impeded 
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without  adequate  SPD,  the  ALCs  have  used  manual  means  or  CASE  tools  to  extract  a  current 
baseline  of  information  from  the  code. 

4.3.3  Lack  of  CALS  Standards  for  SPD 

There  is  a  lack  of  guidance  and  standards  for  applying  CALS  to  SPD  on  current  Air  Force 
contracts.  None  of  the  MIL-STD-1840A  standards  were  designed  for  SPD  and,  as  a  result,  it 
is  difficult  for  SPOs  to  specify  how  to  receive  SPD  digitally  for  PDSS  management  and  use.  In 
addition,  while  many  of  the  emerging  CASE/software  standards  will  eventually  provide  an 
answer,  there  are  limited  choices  currently  available  to  a  SPO.  Since  software  documentation 
(a  subset  of  SPD)  is  primarily  textual  information  with  two-dimensional  graphics  informa¬ 
tion,  it  is  possible  that  some  of  the  MIL^STD-1840A  standards  (e.g.,  IGES,  SGML,  and 
Comite  Consultatif  Internationale  de  Telegraphique  (engush:  International  Consultative 
Committee  on  Telegraphy  and  Telephony  [CCITT]  Group  4  Raster)  could  be  applied  to  SPD 
in  the  interim.  However,  these  solutions  could  limit  the  support  community’s  capability  to 
digitally  update  graphical  representations  such  as  data  flow  diagrams,  structure  charts,  and 
data  base  schemas.  The  capability  to  modify  diagrams  and  related  products  will  exist,  but  the 
intelligence  of  a  CASE  environment  to  support  mission  impact  analysis,  requirements  trace- 
ability,  and/or  intelligent  updates  may  be  impeded.  Ideally,  a  neutral  data  exchange  standard 
will  evolve  that  will  allow  data  from  a  contractor’s  CASE  tool  to  be  ported  for  use  in  an  Air 
Force  CASE  tool  at  an  ALC  or  Using  Command. 

4.3.4  LSA  for  Software 

To  support  software  after  deployment,  several  types  of  logistics  resources  are  needed.  These 
include  test  equipment,  system  software  (operating  systems,  diagnostic  software,  software 
tools,  CASE  tools,  CM  tools,  compilers,  computer  operations  management  software,  etc.), 
hardware  parts,  hardware  support  equipment,  technical  manuals  (e.g.  software  documenta¬ 
tion,  DOD-STD-2167A,  DIDs),  system  training  materials,  etc.  Definition  and  quantifica¬ 
tion  of  these  resources  should  be  performed  during  the  acquisition  phase.  This  can  be 
achieved  through  DOD-STD-2167  A  using  the  DID  entitled  Computer  Resources  Integrated 
Support  Document  (CRISD),  MI-MCCR-80024A  Alternatively,  it  can  be  achieved  through 
application  of  the  LSA  process  to  software.  Independent  of  either  choice,  the  analysis  pro¬ 
vides  an  opportunity  to  identify  the  relationship  between  prime  item  software  and  support 
elements  under  one  comprehensive  CM  system.  It  is  anticipated  that  future  planned  revisions 
to  the  LSA  regulation,  MIL-STD-1388-1 A  and  -2A,  are  expected  to  expand  the  Logistics 
Support  Analysis  Records  (LSAR)  to  capture  software  logistics  resource  requirements. 

Several  studies,  including  ALD's  Supportable  Software  Acquisition  Guide  and  the  Society  of 
Logistics  Engineer's  National  Workshop  on  Software  Logistics  (15-16  August  1989),  have 
advocated  that  the  discipline  of  the  LSA  process  (defined  in  MIL-STD-1388-1  A)  be  applied 
to  the  software  components  of  a  weapon  system  (or  major  equipment  item),  not  just  the  hard¬ 
ware  components,  as  is  most  often  the  case  today.  The  value  of  LSA  is  that  it  forces  an  analysis 
of  the  support  needs  for  the  total  system  in  an  integrated  way.  Each  level  of  the  weapon  sys- 
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tern’s  indenture  structure  is  analyzed  to  define  the  operations  and  maintenance  (O&M)  tasks 
required  to  support  that  component  of  the  weapon  system.  Each  task  is  then  analyzed  to  de¬ 
fine  the  logistics  resources  (e.g.,  parts,  support  equipment,  technical  manuals,  training,  facili¬ 
ties,  etc.)  needed  to  perform  that  task.  Various  modelling  techniques  may  be  employed,  in¬ 
cluding  level  of  repair  analysis  to  identify  the  most  cost-effective  approaches.  Finally,  the 
logistics  resources  are  aggregated,  redundancy  is  minimized,  and  a  total  set  of  estimates  of  the 
logistics  resources  is  reached.  The  estimates  are  then  used  to  initiate  logistics  support  for  the 
system  and  to  prepare  AFLC  to  support  the  new  system. 

Separating  software  from  the  LSA  process  can  detract  from  a  total  systems  analysis  and  can 
result  in  software  support  requirements  not  being  met.  The  ATF  program  is  investigating  the 
application  of  LSA  to  software. 

As  the  Air  Force  implements  a  two  level  maintenance  concept  (placing  maintenance  either  at 
the  flightline  or  at  the  depot  without  an  intermediate  maintenance  site)  there  may  be  an  in¬ 
creasing  requirement  for  performing  LSA  on  software.  LSA  would  specify  which  software 
maintenance  tasks  would  be  performed  at  the  depot  or  on  the  flightline.  This,  in  turn,  would 
more  clearly  define  ALC  responsibilities  for  PDSS  and  Using  Command  responsibilities. 

4.3.5  Software  and  TOs 

There  is  a  significant  relationship  between  software  and  TOs  within  the  Air  Force  today.  Be¬ 
fore  an  ALC  can  issue  revised  software  code  for  installation  on  a  weapon  system  it  must  ob¬ 
tain  a  revised  TO  to  provide  directions  on  how  to  install  the  software  and  describe  the  change 
(see  AFLCR  800-21  and  TO-005-15).  Since  the  TO  change  process  can  take  between  six  to 
nine  months,  this  greatly  increases  the  block  change  process  for  software  modifications.  It 
should  be  noted  that  Using  Commands  are  not  subject  to  this  AFLC  requirement. 

Once  the  CPIN  is  assigned  to  software,  it  can  then  be  referenced  to  TOs;  this  is  a  key  issue  for 
providing  software  CM.  Frequently  TOs  do  not  reference  CPINs;  this  hinders  the  AFLC  in 
modifying  software  and  its  related  TOs.  Since  CPIN  assignments  involve  a  complex  four  page 
form  that  takes  time  to  process,  AFSC  product  divisions  and  their  contractors  often  do  not 
assign  CPINs  to  software  and  software  documentation.  This  results  in  TOs  with  no  CPIN 
references,  creating  a  costly  retrofit  problem  for  AFLC. 

It  is  also  important  that  CPINs  be  updated  when  there  are  significant  software  changes.  This 
is  not  currently  practiced  and  is  not  required  by  the  applicable  regulations. 

4.3.6  Changing  Roles  and  Responsibilities 

As  software  becomes  an  evermore  critical  component  of  Air  Force  weapon  systems  and 
ivms,  roles  of  various  Air  Force  organizations  evolve  to  keep  pace. 

Program  office  priorities  do  not  always  integrate  well  with  support  requirements.  This  is  simi¬ 
lar  to  the  findings  in  the  PDD  Current  Environment  Report ,  i.e.  the  relationship  between  the 
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SPO  and  Logistics  Command  representatives  should  be  complementary,  not  adversarial. 
Frequently,  AFSC  focuses  on  cost  and  schedule  constraints  to  the  detriment  of  long  term  sup¬ 
port  issues.  AFLC  must  move  forward  to  play  a  more  active  role  during  acquisition  so  that  the 
weapon  system  is  not  merely  fieldable  but  supportable.  This  could  be  accomplished  through 
the  early  identification  and  allocation  of  resources  to  carry  the  system  through  PMRT.  In  turn, 
this  would  provide  the  potential  ALC  with  opportunities  to  lead  the  development  of  support 
requirements,  support  training,  and  other  related  issues.  Probably  the  most  critical  task  dur¬ 
ing  development  is  participating  in  the  design  reviews.  Valuable  insight  can  be  gained  by  the 
people  who  will  eventually  be  responsible  for  supporting  the  system.  This  section  focuses  on 
the  changing  roles  and  related  issues  affecting  software  in  AFLC  and  Using  Commands. 

4.3.6.1  AFLC  Role 

Projections  show  that  in  the  near  future  the  ratio  of  software  life  cycle  costs  to  hardware  life- 
cycle  costs  will  be  approximately  four  to  one.  The  majority  of  software  costs  will  occur  in  the 
post-deployment  support  phase.  Currently,  AFLC  personnel  have  limited  participation  in  the 
acquisition  phase.  As  a  result,  they  are  not  familiar  with  the  software  and  associated  products 
before  deployment.  Characteristics  of  the  level  of  AFLC  participation  include: 

•  Limited  or  no  input  to  the  CRLCMP,  the  CRWG,  and  other  support  ve¬ 
hicles, 

•  Limited  training  for  software  issues, 

•  Insufficient  time  to  prepare  for  participation,  and 

•  Limited  or  no  participation  in  design  reviews  for  software  where  much  of 
the  knowledge  about  the  system  can  be  conveyed. 

Funding  source  ambiguity  is  a  major  reason  for  limited  AFLC  participation  in  the  acquisition 
phase.  AFLCR  800-21  states  that  the  acquisition  agency  is  required  to  fund  AFLC  travel  for 
software  technical  reviews.  However,  the  acquisition  agencies  are  not  subject  to  this  regula¬ 
tion  and  do  not  have  this  requirement.  As  a  result,  SPD  is  not  subject  to  a  thorough  review  by 
AFLC  prior  to  PMRT  MA_  personnel  rarely  have  access  to  travel  funds  while  MM  personnel 
may  have  limited  funding  for  these  purposes.  This  continues  to  a  point  where  the  resulting 
documentation  is  often  of  such  poor  quality  that  the  software  cannot  be  supported  effectively. 

Little  or  no  coordination  between  Commands  in  preparing  to  support  weapon  system  soft¬ 
ware  can  often  result  in  AFLC  establishing  software  support  facility  requirements  without 
proper  input  from  the  user  or  acquisition  agencies.  This  makes  the  acquisition  agency  hesi¬ 
tant  to  commit  funding  for  the  support  facility.  As  a  result,  the  support  facility  is  often  not 
available  until  after  support  responsibility  has  been  transferred  to  AFLC.  Even  though  some 
recent  programs  such  as  the  ESD  Rapid  Execution  and  Combat  Targeting  (REACT)  Program 
have  not  followed  this  practice,  the  problem  continues  to  occur. 

AFLC  has  assigned  DPMLs  to  increase  the  AFLC’s  visibility  in  the  acquisition  process.  The 
DPML  is  often  responsible  for  more  than  one  acquisition  program  at  a  time  (particularly  for 
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small  programs),  and  is  therefore  unable  to  provide  in-depth  coverage  of  logistics  on  any  one 
acquisition  program.  Another  disadvantage  is  that  the  DPMLs  duties  are  management-ori¬ 
ented;  this  results  in  AFLC  software  development  technical  issues  not  being  addressed  in  de¬ 
tail.  Finally,  DPMLs  are  frequently  not  adequately  supported  by  either  ALD  or  the  ALCs  in 
providing  detailed  requirements. 

43.6.2  Using  Command  Role 

The  role  of  Using  Commands  in  PDSS  is  growing.  In  many  instances,  the  Using  Command  is 
responsible  for  supporting  the  applications  software  (mission-unique  software),  while  AFLC 
is  responsible  for  the  system  software  (operating  system.  Commercial  Off-The-Shelf  (COTS) 
software,  etc.).  AFR  800-14  describes  five  alternative  approaches  to  PDSS,  ranging  from 
100%  AFLC  support  of  all  MCCR  software  for  a  weapon  system  to  100%  Using  Command 
support,  with  variations  of  shared  support  in  between.  An  example  of  growing  Using  Com¬ 
mand  involvement  is  ESD’s  REACT  Program.  Under  this  program,  SAC  will  receive  a  User 
Maintenance  facility  (consisting  of  computers  and  automated  tools)  and  maintenance  train¬ 
ing  to  support  SAC’s  PDSS  efforts.  Another  example  is  within  the  AWACS  Program,  in  which 
TAC  may  initiate  changes  to  mission  software  as  well  as  development  and  coding  of  changes. 

The  user  is  one  of  the  few  participants  involved  in  both  the  acquisition  and  support  processes 
throughout  the  life  cycle.  The  user  and  the  designer  are  two  key  participants  in  the  acquisition 
process,  in  contrast  to  the  user  and  the  maintainer  in  the  support  processes.  There  is  continu¬ 
ity  in  the  role  of  the  Using  Command  from  the  Statement  of  Need  to  disposal/retirement  of 
the  system. 

4.3.7  Use  of  IV&V 

The  IV&V  process  is  the  review  of  software  products  for  functional  and  technical  sufficiency 
by  an  independent  organization.  Currently,  IV&V  is  performed  only  when  the  acquisition 
agency  has  adequate  funding.  Rarely  is  it  initiated  before  coding  has  begun.  To  to  be  effec¬ 
tive,  IV&V  should  be  initiated  during  the  definition  of  requirements.  In  this  way,  the  IV&V 
agent  can  review  the  requirements,  the  design,  and  the  code  before  each  gets  approved 
against  the  available  baselines.  Since  IV&V  is  the  primary  method  for  insuring  that  support 
issues  are  adequately  addressed  during  the  acquisition  process,  the  ALC  sometimes  acts  as 
the  IV&V  agent,  either  by  doing  the  work  itself  or  by  hiring  a  contractor.  With  this  role,  the 
ALC  is  better  able  to  ensure  that  the  software  is  supportable  since  the  center  will  have  support 
responsibility  for  several  decades.  Examples  of  ALC  management  of  IV&V  include:  OO- 
ALC/MAS,  which  uses  20%  of  its  workload  to  perform  IV&V;  and  SA-ALC/MM  for  the 
F-lll.  FIGURE  4-2  shows  the  traditional  relationship  between  the  acquisition  agency,  the 
prime  contractor,  and  the  IV&V  contractor.  FIGURE  4-3  shows  how  this  relationship  is 
emerging  in  some  programs  today  in  a  manner  which  better  achieves  supportability  objec¬ 
tives.  The  approach  of  having  the  ALC  manage  IV&V  processes  should  be  practiced  more 
widely. 
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FIGURE  4-2.  TRADITIONAL  IV&V  RELATIONSHIPS 


FIGURE  4-3.  EMERGING  IV&V  RELATIONSHIPS 
4.3.8  DOD-STD-2167A 

Use  of  DOD-STD-2167A  in  Ar  Force  acquisitions  is  evolving  slowly.  The  majority  of  past 
acquisition  programs  do  not  use  the  standard;  similarly,  most  software  modification  programs 
do  not  follow  the  standard.  As  a  result,  the  majority  of  ALC  software  personnel  and  software 
projects  do  not  use  DOD-STD-2167A  One  example  is  the  Rail  Garrison  Program,  which 
does  not  plan  to  use  the  standard  because  the  original  missile  program  did  not  follow  it. 

DOD-STD-2167A  is  the  primary  standard  governing  MCCR  software  development  and,  in¬ 
directly,  the  entire  MCCR  software  life  cycle.  Its  slow  implementation  creates  a  lack  of  docu¬ 
mentation  and  rigor  in  the  software  acquisition  process.  Athough  2167Ahas  its  limitations 
(primarily  due  to  advances  in  software  approaches  and  technology),  it  is  still  a  sound  frame¬ 
work  from  which  to  undertake  a  software  development  project  by  using  classical  steps  in  sys¬ 
tems  analysis  and  by  providing  tailoring  flexibility  where  particular  requirements  do  not  apply 
to  a  program  or  are  not  cost-effective. 
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Some  recent  acquisition  programs  that  do  use  DOD-STD-2167A  include:  the  USTS, 
AWACS  Radar  Improvement  Program,  a  current  modification  to  the  A-10,  and  the  F-117A 
ATF.  The  ATF  is  using  DOD-STD-2167A  with  additional,  newly  created  DIDs  that  meet 
ATF  requirements.  These  DIDs  expand  the  amount  of  information  that  the  Air  Force  will 
receive  for  PDSS  functions,  including  more  detail  on  the  design  approach  and  trade-offs  in¬ 
volved  in  the  software  design  process.  These  items  will  also  address  combining  several  ancil¬ 
lary  documents  available  under  DOD-STD-2167A  into  one  deliverable. 

4.3.9  CASE  Tools 

The  Air  Force  PDSS  community  is  not  utilizing  CASE  tools  to  the  same  degree  as  private 
industry.  While  many  acquisition  programs  have  contractors  who  are  using  CASE  tools.  Air 
Force  PDSS  personnel  often  do  not  receive  or  obtain  CASE  tools  to  support  software  and 
documentation  maintenance.  This  results  in  a  labor-intensive  process  for  PDSS.  In  selected 
recent  acquisition  programs,  CASE  tools  are  being  employed.  For  example,  at  ESD,  the  con¬ 
tractor  supporting  the  REACT  Program  is  employing  ICONIX  (in  contrast,  within  the  same 
division,  the  USTS  program  is  not  using  CASE  tools).  In  recent  AFSPACECOM  acquisitions 
contractor  are  also  using  CASE  tools. 

Current  CASE  tool  products  are  largely  confined  to  the  front  end  of  the  life  cycle  (require¬ 
ments  and  design)  and  the  back  end  (programming).  It  is  anticipated  that  CASE  tools  will 
soon  offer  full  integration  over  the  entire  life  cycle;  this  would  support  the  automated  genera¬ 
tion  of  design  documentation  and  source  code  from  requirements.  The  real  value  of  such  an 
automated  tool  is  that  once  the  documentation  and  code  are  available,  a  change  to  either  one 
could  conceivably  generate  the  appropriate  change  in  related  SPD. 

Some  CASE  tools  offer  a  limited  capability  to  generate  software  documentation  in  DOD- 
STD-2167A  format.  However,  these  capabilities  are  usually  limited  to  document  templates, 
which  must  then  be  completed  by  an  analyst  copying  documentation  and  diagrams  into  the 
templates.  Hopefully,  in  the  future,  these  capabilities  will  improve  the  software  documenta¬ 
tion  process.  FIGURE  4-4  illustrates  the  evolution  of  CASE  tools  from  the  current  stand¬ 
alone  capability  of  providing  in-depth  support  only  during  programming,  to  a  future  capabili¬ 
ty  of  using  a  common  database  to  support  a  diverse  set  of  documentation,  design,  and  coding 
tools. 

Significant  improvements  in  productivity  require  a  common  database  or  repository  that 
would  have  in  its  lexicon  the  ability  to  freely  translate  between  requirements  language,  design 
language,  and  implementation  language.  This  would  require  a  series  of  compilers  or  inter¬ 
preters  that  would  be  similar  in  function  to  the  compiler  that  translates  source  code  into  ob¬ 
ject  code.  The  Information  Resource  Dictionary  System  (IRDS)  Standard  Committee  at  the 
National  Institute  of  Standards  &  Technology  (NIST)  is  helping  to  meet  this  goal.  It  would 
function  as  a  meta  data  dictionary  that  would  be  an  automated  data  administrator  and  inte¬ 
grator  of  all  the  software  engineering  environments  acceptable  to  the  Air  Force.  Enforce¬ 
ment  of  this  concept  will  be  similar  to  the  Air  Force’s  approach  to  selection  of  Higher  Order 
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Languages  (HOLs),  i.e.,  as  long  as  the  HOLis  on  the  list  of  acceptable  HOLs  to  the  Air  Force, 
a  contractor  is  free  to  select  it. 


FIGURE  4-4.  CASE  TOOL  EVOLUTION 
4.3.10  Testing  Issues  Need  to  Be  Identified  Early 

Previous  studies  on  ECS  software,  such  as  the  1980  TRW  study,  reported  that  as  much  as  40% 
of  all  software  delivered  at  PMRT  does  not  function  as  intended  due  to  inadequate  time  spent 
on  software  testing.  Ideally,  a  greater  portion  of  the  development  life  cycle  (not  necessarily  a 
longer  life  cycle)  should  be  devoted  to  requirements,  design  and  testing,  in  contrast  to  the 
current  practice. 

The  Air  Force  does  not  emphasize  the  need  for  independent  test  agencies  responsible  for 
OT&E  to  actively  participate  in  the  initial  requirements  and  design  phases  of  the  life  cycle. 
Such  early  involvement  would  allow  test  agencies  to  identify  problems  that  could  cause  com¬ 
plications  during  testing,  in  the  initial  stages  of  the  development  cycle.  Problems  corrected  in 
the  design  phase  are  less  costly  to  fix  than  those  identified  during  coding.  This  independent 
and  operational  test  is  important  for  two  reasons:  developers  should  not  be  the  sole  testers  of 
their  code,  and  an  operational  test  can  reveal  problems  that  might  not  arise  in  a  test  environ¬ 
ment.  Under  current  practices,  software  support  environments  are  identified  so  late  in  the 
acquisition  cycle  that  they  are  not  adequately  tested  during  OT&E.  As  a  result,  their  adequa¬ 
cy  for  software  support  cannot  be  evaluated. 

A  further  hindrance  to  adequate  testing  is  the  failure  to  ensure  that  stated  requirements  meet 
the  following  criteria: 


•  Realistic  -  requirements  can  be  feasibly  met  by  a  computer  system  within 
cost,  schedule,  scope  and  supportability  constraints. 

•  Unambiguous  -  requirements  are  understandable  by  journeyman-level 
software  engineers,  without  in-depth  project  understanding. 

•  Consistent  -  requirements  do  not  conflict  across  related  documents. 

•  Necessary  -  requirements  are  essential  to  meet  the  mission  and  constitute  a 
reasonable  resulting  expenditure. 

•  Complete  -  requirements  are  comprehensive  and  support  all  mission  re¬ 
quirements. 

These  criteria  are  necessary  for  structuring  testing  so  that  there  is  tangible  proof  that  the  soft¬ 
ware  satisfies  each  stated  requirement.  FIGURE  4-5  describes  some  of  the  requirements 
that  should  be  testable. 


STATE  WHAT  SOFTWARE  IS  TO  DO  IN  TERMS  OF: 
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INTERFACES  |  SIZING 


INPUTS 


OUTPUTS 


CONSTRAINTS 


FIGURE  4-5.  TESTABLE  REQUIREMENTS 
4.3.11  Retention  and  Training  of  Software  Personnel 

Current  employment  surveys  indicate  that  the  United  States  will  experience  a  severe  shortage 
of  software  engineering  personnel  in  the  1990s.  With  large  ( >  1  million  line  of  code)  softwa¬ 
re-intensive  systems  such  as  the  B-l,  B-2,  ATF,  C-17,  SDI,  etc.,  coming  into  the  inventory, 
this  projected  shortage  of  software  personnel  may  eventually  impair  mission  readiness.  The 
projected  demand  for  software  engineering  personnel  will  allowengineers  to  choose  the  most 
appealing  software  area  in  which  to  work.  Most  software  personnel  prefer  development  work 
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over  maintenance  work.  This  projected  shortage  will  become  even  more  severe  for  the  Air 
Force,  whose  primary  need  is  software  maintenance  personnel.  In  one  instance,  the  AWACS 
Program  initiated  no  modifications  from  PMRT  in  1976  until  1988  due  to  the  extensive  train¬ 
ing  required  to  “ramp  up”  the  software  engineering  personnel,  and  to  the  high  turnover  of 
personnel. 

Even  though  several  ALCs  have  increased  the  grade  levels  for  some  software  personnel  (at 
OO-ALC,  several  software  maintenance  engineering  positions  have  been  established  at  the 
GS-13  level),  there  remains  a  sizeable  pay  disparity  between  the  government  and  private  in¬ 
dustry,  which  makes  it  difficult  for  the  Air  Force  to  retain  personnel. 

The  Air  Force  is  not  providing  adequate  training  for  either  software  acquisition  or  software 
maintenance  personnel.  The  Air  Force  fills  many  of  its  software  acquisition  positions  with 
personnel  in  transition  from  another  career.  Even  though  these  individuals  are  provided  with 
some  formal  software  acquisition  training,  they  have  little  on-the-job  experience  in  software 
acquisition  prior  their  assignment  as  program  manager  of  a  complex  software-based  system. 
Currently,  training  for  software  maintenance  personnel  focuses  on  developing  familiarity 
with  source  code  and  operating  systems,  with  little  emphasis  on  orientation  to  the  overall 
weapon  system  and  the  requirements  that  the  system  was  meant  to  satisfy. 

A  study  of  ECS  personnel  by  TRW  in  1980  indicated  that  it  can  require  as  long  as  three  years 
for  software  support  personnel  to  master  a  CSCI  containing  10-20  thousand  lines  of  code  if 
they  were  not  intensively  involved  in  developing  the  code.  The  Air  Force  still  tends  to  view 
software  training  as  a  subset  of  hardware  training.  There  is  little  recognition  that  the  training 
philosophies  are  significantly  different. 

4.4  CONCLUSION 

This  section  described  the  major  findings  from  an  examination  of  the  current  Air  Force  soft¬ 
ware  environment  relating  to  CALS.  These  findings  also  include  a  quantitative  view  of  SPD 
in  the  Air  Force.  The  findings  show  that  there  are  significant  opportunities  to  apply  CALS 
to  the  digital  receipt,  management,  storage,  distribution,  use,  and  configuration  management 
of  SPD. 


APPENDICES 


RELATED  STUDIES 
IDEE  DIAGRAMS 
BIBLIOGRAPHY 


POINTS  OF  CONTACT 


APPENDIX  A: 
RELATED  STUDIES 


A.l  INTRODUCTION 


There  have  been  several  studies  of  Air  Force  software  problems  since  the  late  1970s.  Some  of 
these  studies  address  only  the  acquisition  phase  of  the  software  development  life  cycle.  Many 
of  the  problems  identified  in  these  studies  have  remained  unresolved  and  are  identified  again 
in  the  later  studies.  Among  the  most  common  problems  are: 

•  Ineffective  configuration  management, 

•  Insufficient  documentation, 

•  Shortage  of  software  maintenance  personnel,  and 

•  Insufficient  integration  of  CASE  tools. 

Other  studies  were  reviewed  to  help  understand  and  define  the  current  Air  Force  software 
development  and  support  environments.  Some  of  these  studies  are  summarized  below,  in 
Section  A2. 

A.2  MAJOR  STUDIES 

A.2.1  Air  Force  Studies  Board  (1976, 1983,  1985) 

The  Board  published  studies  of  Air  Force  software  management  practices  in  1976, 1983,  and 
1985.  All  three  studies  found  that  the  Air  Force  was  not  adequately  defining  software  re¬ 
quirements  for  its  systems  prior  to  coding.  'They  recommended  that  an  evolutionary  approach 
be  used,  i.e.,  build  only  what  has  been  thoroughly  defined,  test  it,  and  then  use  it  to  stimulate 
additional  well-defined  requirements  for  building  additional  software.  Another  problem  the 
Board  found  was  that  while  people  know  and  accept  the  limitations  of  hardware,  the  limita¬ 
tions  of  software  were  not  so  readily  understood  and  accepted. 

The  Board  noted  the  absence  of  integrated  Computer-aided  Software  Engineering  (CASE) 
tools.  While  these  tools  promise  a  great  deal,  their  usefulness  is  limited  to  selected  portions 
of  the  development  cycle.  The  Board  recommended  that  the  Air  Force  select  an  off-the-shelf 
software  engineering  environment  containing  CASE  tools  for  the  short  term,  and  develop  a 
customized  environment  for  the  long  term.  This  customized  environment  should  rely  heavily 
on  expert  systems  so  that  a  proposed  change  to  a  portion  of  the  software  can  be  automatically 
analyzed  to  determine  the  potential  impact  on  the  software  as  a  whole. 

The  Board  criticized  the  Air  Force  for  not  providing  long-term  technical  training  to  software 
development  and  maintenance  personnel.  The  quality  of  the  training  should  be  similar  to  that 
provided  for  pilots.  The  Board  was  also  critical  of  the  fragmented  software  configuration 
management  practices  of  the  Air  Force. 

A.2.2  U.S.  Navy  Software  Maintenance  Study  (1987) 

Even  though  this  is  a  study  of  Navy  software,  its  findings  are  of  interest  to  the  Air  Force.  This 
study  found  that  software  support  people  r°°d  *c  have  knowledge  of  the  weapon  system,  on- 
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the-job  training  with  software  developers,  hardware/operating  system  training,  and  extensive 
experience  with  the  HOL  used  by  the  system.  A  truly  integrated  support  environment  re¬ 
quires  that  all  tools,  from  documentation  through  programming,  utilize  a  common  data  base. 
An  effective  tool  is  one  that  is  non-modal.  A  non-modal  tool  can  be  used  in  more  than  one 
mode  at  a  time,  e.g..  to  perform  debug  and  edit  operations  simultaneously. 

This  study  emphasizes  that  integrated  tools  are  available  mostly  for  the  development  phase. 
Few  are  useful  in  the  support  phase.  This  study  also  stated  tnat  regression  testing  is  a  major 
part  of  software  support  since  it  ensures  that  a  change  to  a  part  of  the  software  does  not  ad¬ 
versely  affect  overall  software  performance.  It  is  imperative  that  software  support  personnel 
be  thoroughly  familiar  with  the  software  because  of  the  wide-ranging  implications  of  chang¬ 
ing  the  software.  The  software  support  task  is  best  served  by  an  approach  that  stresses  the 
importance  of  knowing  how  the  software  was  developed,  i.e.,  what  its  design  philosophy  is. 
More  time  should  be  devoted  to  req,,;  Yemenis  analysis  and  software  design.  If  requirements 
and  design  are  properly  completed,  coding  should  not  require  more  than  20%  of  the  develop¬ 
ment  time. 

Frequent,  in-depth  walk-through  of  design  and  code  are  the  key  to  ensuring  that  the  software 
performs  as  required.  The  military  should  use  communication  networks  such  as  the  Defense 
Data  Network  (DDN)  and  engineering  workstations  to  establish  software  development  and 
support  networks  for  use  by  development,  user,  and  support  personnel.  Such  networks  would 
provide  a  real-time  review  of  documentation  and  automatic  update  of  documentation  con¬ 
current  with  code  changes.  It  would  improve  communications  and  reduce  travel  time  and 
expenses.  To  do  this,  either  a  structured,  graphical  technique  or  translating  devices  should  be 
used  to  link  requirements,  design,  and  coding  in  much  the  same  way  that  compilers  link 
source  and  object  code. 

A.2.3  TRW  Study  of  Air  Force  ECS  Software  (1980) 

This  study  reviewed  the  problems  associated  with  all  five  categories  of  ECS  software.  The 
study  identifies  shortage  of  trained  software  support  personnel,  lack  of  software  configura¬ 
tion  management,  and  poor  quality/incomplete  documentation  as  the  major  problems  plagu¬ 
ing  software.  The  study  concludes  that  the  documentation  issue  is  a  major  reason  for  the  fail¬ 
ure  of  software  configuration  management.  One  of  the  major  findings  is  that  25-40%  of  all 
ECS  software  does  not  function  properly  when  turned  over  to  AFLC  at  PMRT.  Support  of 
most  ECS  software  is  fragmented  between  AFLC  and  the  user.  The  failure  to  centrally  man¬ 
age  software  development  also  contributes  to  ineffective  software  configuration  manage¬ 
ment.  The  study  emphasizes  that  software  support  for  changes/modifications  to  existing  soft¬ 
ware  is  usually  more  complex  than  the  original  development  effort.  As  a  result,  a  complete 
life  cycle  software  support  facility  and  full  set  of  documentation  must  be  available  for  software 
support.  Yet  software  support  personnel  often  have  little  more  than  source  code  with  which  to 
work.  Documentation  either  does  not  reflect  the  current  configuration  of  the  code  or  is  un¬ 
available.  Lack  of  current  documentation  hinders  not  only  software  support  but  also  compet- 
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itive  re-procurement.  To  be  effective.  IV&V  should  start  during  the  review  of  system  require¬ 
ments  and  design. 

A. 2.4  Journal  of  Defense  Systems  Acquisition  Management  Studies  of  Software 
Maintenance  (1982) 

This  study  emphasizes  the  need  to  address  maintenance  and  training  requirements  at  the 
same  time  that  mission  and  technical  requirements  are  addressed.  This  usually  does  not  hap¬ 
pen  because  AFLC  is  not  adequately  represented  during  the  development  process.  Require¬ 
ments  need  to  be  stated  in  a  way  that  makes  them  testable.  Experience  shows  that  the  more 
.  •"•'pirtety  automated  anu  testable  the  software  requirements  are,  the  lower  the  develop¬ 
ment  cost.  Current  communications  electronics  systems  represent  the  initial  departure  from 
previous  manual  systems,  and  their  users  find  it  difficult  to  articulate  requirements.  In  such 
circumstances,  iterative  prototyping  is  the  most  efficient  way  to  define  requirements.  The 
structured  methodology  of  DOD-STD-2167A  is  not  suited  to  this  type  of  software  develop¬ 
ment.  The  government  should  state  only  what  is  required  and  not  dictate  how  the  require¬ 
ments  are  to  be  satisfied.  Configuration  control  of  software  should  not  start  until  software 
baselines  have  been  established.  The  length  of  time  needed  for  software  support  personnel  to 
acquire  in-depth  knowledge  depends  on  how  involved  they  are  in  the  development  cycle.  All 
software  and  documentation  changes  and  configuration  management  should  be  centralized. 
Testing  of  changes  should  be  performed  by  the  user. 

A.2.5  PDSS  Study  for  the  F-16  (Current) 

The  Software  Engineering  Institute  (SEI)  is  currently  studying  how  software  for  the  F-16D  is 
supported  by  OO-ALC.  A  behavioral  analysis  tool  called  State  Mate  is  being  used  in  the 
study.  It  depicts  information  flows  among  all  the  Ogden  functions  that  support  F-16D  soft¬ 
ware.  The  SETs  methodology  includes  many  detailed  interviews  with  a  carefully  selected 
group  of  key  F-16  software  support  personnel.  These  interviews  have  been  going  on  for  over 
a  year.  They  will  be  used  to  model  the  current  support  process.  The  F-16D  is  equipped  with 
15  complete  systems.  300  digital  processors,  and  has  over  250,000  lines  of  code. 

A. 2.6  DOD  Master  Plan  (1989) 

The  DOD  has  started  to  assess  all  of  the  software  improvement  studies  performed  for  the 
services  over  the  past  decade.  This  study  will  be  used  to  develop  a  plan  for  implementing 
some  of  the  specific  recommendations  of  the  studies.  This  DOD  effort  has  recognized  that 
most  of  the  problems  uncovered  by  the  earliest  studies  (pre  1979)  continue  to  be  found  by  the 
more  recent  studies.  The  study  will  therefore  focus  on  what  are  considered  to  be  the  twelve 
best  previous  studies.  Another  characteristic  of  all  of  the  studies  is  that  recommendations 
were  too  general,  e.g.,  enhance  the  education  of  software  personnel,  and  that  there  was  very 
little  detail  about  how  to  implement  recommendations.  The  DOD  Software  Master  Plan 
Study  is  committed  to  provide  detailed  solutions  to  these  problems.  The  first  task  of  the  study 
is  to  analyze  all  of  the  government  directives,  standards,  etc.,  for  software  development  and 
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support  to  determine  the  applicability,  redundancy,  and  consistency  of  the  material.  To  date 
the  study  has  identified  over  200  documents  related  to  software  development  and  support. 
The  study  is  also  cataloging  DOD’s  current  software  research  and  development  efforts  and 
will  identify  all  DOD  units  that  have  software  management  roles.  The  goal  of  the  Master  Plan 
is  to  lay  out  a  five-year  implementation  plan  to  determine  responsibilities,  schedules,  mile¬ 
stones,  and  required  funding.  A  draft  of  the  DOD  Software  Master  Plan  was  issued  in  Febru¬ 
ary  1990. 

A.2.7  Software  Technology  for  Adaptable  and  Reliable  Systems  (STARS)  (1988) 

This  program  is  administered  by  the  Defense  Advanced  Research  Projects  Agency  (DARPA) 
to  improve  software  engineering  techniques  and  disseminate  them  to  industry.  To  date,  three 
contracts  have  been  awarded  to  develop  tools  for  creating  and  managing  re-usable  machine- 
independent  Ada  code.  STARS  has  recently  been  criticized  for  making  it  difficult  for  industry 
to  obtain  the  tools  being  developed  under  the  program.  The  program  has  also  recently  an¬ 
nounced  a  change  in  goal  due  to  the  need  for  a  standardized  environment;  to  focus  on  devel¬ 
oping  a  life  cycle  software  support  environment. 

A.2.8  Purdue  University  Study  on  Software  Development  Documentation  (1988) 

This  study  focuses  on  documentation  for  software  development.  It  does  not  address  the  need 
for  documentation  during  the  support  phase.  Recommendations  are  that  documentation  be 
transferred  electronically  between  the  Air  Force  and  contractors  during  development. 

A.2.9  MITRE  SPD  Study  (1989) 

MITRE  Corporation  has  begun  a  study  on  the  management  of  C3  documentation  in  a  digital 
format.  Currently,  MITRE  is  trying  to  establish  a  standard  for  transferring  cost  data  between 
the  government  and  industry  via  floppy  disks.  There  are  no  current  plans  to  consider  the  issue 
of  electronically  transferring  all  software-related  data  between  the  government  and  industry. 

A.3  RELATED  INITIATIVES 

There  are  a  number  of  initiatives  concerning  the  scope  of  the  SPD  Program.  These  include: 

•  BOLD  STROKE  -  This  is  an  Air  Force  Senior  Officer  Software  Manage¬ 
ment  course  offered  by  the  Technology  Management  School  at  Maxwell 
AFB,  AL.  The  course  originated  from  a  Software  Management  Action 
Plan  issued  on  29  November  1985  and  summarizes  Air  Force  management 
approaches,  fundamentals,  and  problems  involving  software.  It  includes  a 
series  of  briefings  to  apprise  senior  officers  of  software  management.  The 
course  states  that  the  ability  of  the  Air  Force  to  manage  software  is  the  key 
to  mission  readiness  and  that  software  must  by  treated  as  a  key  component 
of  the  system  life  cycle. 

•  Joint  Logistics  Commanders  Workshop  on  Post  Deployment  Software  Sup¬ 
port  (Orlando  I  and  II)  -  Logistics  Commands  from  the  Army,  Navy.  Air 
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Force  and  Marine  Corps  sponsored  conferences  on  software  support  con¬ 
cerns  in  1983  (Oriando  1)  and  1987  (Orlando  II) .  The  topics  addressed  in¬ 
cluded  IV&V,  cost  of  ownership,  software  support  environment,  software 
change  process  and  configuration  management,  forecasting  PDSS  resource 
requirements,  and  PDSS  standards. 

•  NSIA  Committees  -  The  National  Security  Industrial  Association  (NSIA)  is 
sponsoring  several  committees  that  are  active  in  addressing  CALS.  The  In¬ 
formation  Technology  Committee  includes  two  subcommittees;  a  Software 
Subcommittee  and  a  Software  Standards  Subcommittee.  Committee  mem¬ 
bers  have  recently  added  a  Software  Products  Interest  Group  to  the  elfcL 
to  develop  the  Product  Data  Exchange  Standard  (PDES). 

•  Software  Standards  -  A  variety  of  software  standards  are  in  development 
that  will  facilitate  a  neutral  exchange  of  software  and  data.  These  efforts 
address  some  or  all  of  the  following  issues:  tool  portability,  open  architec¬ 
ture,  data  exchange,  tool  integration,  repository  architecture,  and  user  in¬ 
terface,  in  the  United  States  as  well  as  Europe,  and  Japan.  These  efforts 
include: 

o  Information  Resource  Dictionary  System  (IRDS), 
o  Portable  Common  Tool  Environment  (PCTE), 
o  CASE  Integration  Services  (CIS), 

o  Common  APSE  Tnterface  Set  (CAIS)  -  Ada  environments,  and 
o  CASE  Data  Interchange  Format  (CDIF). 

Phase  II  of  the  modular  planning  process.  Technology  Assessments,  will  ex¬ 
amine  these  further. 
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APPENDIX  B: 
IDEF  DIAGRAMS 


B.l  INTRODUCTION 


Section  3  of  this  report  contains  an  explanation  of  the  EDEF  methodology  and  why  it  was  used 
in  the  analysis  of  the  SPD  current  environment.  This  appendix  presents  the  complete  set  of 
IDEF  diagrams  required  to  describe  the  current  software  environment  in  detail  down  to  level 
4.  FIGURE  B-l  is  a  top  level  IDEF  node  tree  of  the  SPD  environment.  By  showing  the 
hierarchy  of  functions  from  general  to  detailed  the  node  tree  provides  a  reference  point  for 
understanding  the  activities  and  decomposition  represented  in  the  detailed  IDEF  diagrams 
which  follow. 

B.2  DETAILED  IDEFs  OF  THE  SPD  PROCESS 

The  SPD  process  covers  two  major  activities:  acquisition  and  deployment/management.  This 
appendix  examines  both  activities  and  presents  a  high  level  node  tree  for  each  activity  fol¬ 
lowed  by  detailed  IDEF  diagrams  and  text  describing  each  IDEF.  For  a  better  understanding 
of  the  process,  text  and  the  IDEF  diagrams  appear  on  opposite  pages. 

B.2.1  Acquisition  IDEFs 

The  SPD  acquisition  node  tree  (FIGURE  B-2)  shows  that  the  acquisition  function  is  respon¬ 
sible  for  the  majority  of  software  products.  These  products  are  needed  throughout  the  PDSS 
cycle.  The  system  must  adjust  to  changes  in  the  mission,  so  that  “software  maintenance”  is,  in 
essence,  further  software  development. 


B-l 


Level  0  Design,  Develop  &  Manage 

Weapon  System  Software 
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FIGURE  B-l.  SPD  TOP  LEVEL  NODE  TREE 


Acquire  Weapon  SPD  NODE  TREE 

L«vel  1  System  Software 
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FIGURE  B-2.  SPD  ACQUISITION  NODE  TREE 


B.2.1.1  Design,  Develop  &  Manage  Weapon  System  Software  -  Node  A-0 

This  is  the  top  level  node  in  the  network,  representing  all  activity  within  the  ECS  software 
life  cycle.  At  this  level,  the  major  inputs  are  the  system  requirements.  The  activities  include 
the  design  w-ork,  development  of  the  software,  integration  into  the  weapon  system  or  end 
item,  and  management  throughout  the  system  life  cycle.  The  output  of  this  activity  is  to  pro¬ 
vide  the  system  capabilities  that  satisfy  system  requirements. 

Design,  Develop  &  Manage  Weapon  System  Software  -  Box  A-0 

INPUTS; 

OUTPUTS: 

CONTROLS: 

700-9, 

5010.12 

MECHANISMS: 


Initial  System  Requirements 
Mission/System  Capabilities 

DODD  5012.19,  AFR  65-3,  AFSCP  800-7,  MIL-STD-483A, 
DOD-STD-480B,  DODD  5000.3,  AFR  80-14,  AFR  800-19, 
AFSCP/ AFLCP  800-18,  DODD  5000.29,  DODD  5000.31,  AFR 

DOD-STD-2167A,  MIL-STD-2168,  AFLCR  800-21,  DODD 

AFR  800-14.  AFR  310-1,  DOD-STD-1467,  AFSCP  800-3 
SPO/SAM/DPML,  SPM/CRWG  (ALCs),  Using  Command,  Contractor 
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B.2.1.2  Design,  Develop  &  Manage  Weapon  System  Software  -  Node  AO 


Node  AO  is  comprised  of  two  major  activities,  the  acquisition  (Node  Al)  and  the  deployment/ 
management  (Node  A2).  The  acquisition  node  is  responsible  for  the  majority  of  software 
products.  These  products  are  needed  throughout  the  PDSS  cycle.  The  system  must  adjust  to 
changes  in  the  mission,  so  that  “software  maintenance”  is  predominantly  software  develop¬ 
ment. 


Acquire  Weapon  System  Software  -  Box  Al 


INPUTS: 

OUTPUTS: 

CONTROLS: 


MECHANISMS: 


Mission  Requirements,  PMD,  MENS,  SON,  PMP,  SEMP,  CMP,  SOC 
Tested  CSCIs,  SPD,  CRLCMP,  Configuration  Data,  CRISP,  O/S  CMP 
DODD  5012.19,  AFR  65-3,  MIL-STD-480,  AFSCP  800-7, 
MIL-STD-493A,  AFR  800-4,  DODD  5000.31,  AFR  700-9, 

DODD  5000.3,  AFR  80-14,  AFR  800-19,  DOD-STD-2167A, 
DOD-STD-2168 

Product  Divisions,  Using  Commands,  ALCs,  Contractors 


Deploy  &  Manage  Weapon  System  Software  -  Box  A2 


INPUTS: 

OUTPUTS: 

CONTROLS: 

STD-2168 

MECHANISMS: 


Block  Change  Cycle,  Tested  CSCIs,  SPD,  CRLCMP,  Configuration 
Data,  CRISP,  O/S  CMP  (CRLCMP) 

Mission/System  Capabilities 

AFLCR  800-21,  DODD  5010.12,  AFR  800-14,  AFR  310-1, 
DOD-STD-1467,  AFSCP  800-3,  DOD-STD-2167A,  DOD- 


ALCs,  Using  Commands,  Support  Contractor 


n-6 


B.2.1.3  Acquire  Weapon  System  Software  -  Node  A1 


This  activity  comprises  all  development  activity  up  to  and  including  PMRT.  The  acquisition  is 
broken  out  into  the  four  phases.  It  is  not  until  FSD  that  software  actually  is  developed.  How¬ 
ever,  the  system  concept  will  have  an  effect  on  what  software  will  be  required. 


Conduct  Concept  Exploration  -  Box  All 


INPUTS: 

OUTPUTS: 

CONTROLS: 


MECHANISMS: 


Mission  Requirements 
System  Concepts,  SOC 

DODD  5012.19,  AFR  65-3,  MIL-STD-480,  MID-STD-490 A 
DODD  5000.31,  AFR  700-9,  DOD-STD-2167A, 
DOD-STD-2168 
SPO/Contractor 


Conduct  Demonstration /Validation  -  Box  A12 


INPUTS: 

OUTPUTS: 

CONTROLS: 


MECHANISMS: 


System  Concepts 

Validated  System  Requirements,  SSS  Functional  Baseline 
DODD  5012.19,  AFR  65-3,  MIL-STD-480,  MIL-STD-490A 
DODD  5000.31,  AFR  700-9,  DOD-STD-2167A, 
DOD-STD-2168 


SPO/Contractor 


Conduct  Full  Scale  Development  -  Box  A13 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


Validated  System  Requirements 

Tested,  Integrated  CSCIs 

DODD  5000.31,  AFR  700-9,  DOD-STD-2167A, 

DOD-STD-2168,  AFR  80-14,  AFR  800-19,  MIL-STD-1521B 

SPO/Contractor 


Initiate  Production  /Deployment  -  Box  A14 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


Tested,  Integrated  CSCIs 
CSDIs 

DOD-STD-2167A,  DOD-STD-2168,  AFR  80-14, 
MIL-STD-1521B,  AFR  800-4,  AFR  800-19 
SPO/Contractor 
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B.2.1.4  Conduct  Concept  Exploration  -  Node  All 


The  concept  exploration  phase,  the  primary  phase  in  the  system  acquisition  life  cycle,  is  re¬ 
sponsible  for  the  development  of  proposals  which  initially  satisfy  the  system  need.  To  deter¬ 
mine  the  viability  of  these  proposals,  risk  and  schedule  assessments  are  performed,  as  well  as 
a  general  feasibility  study. 

Conduct  Engineering  Studies  -  Box  Alll 

INPUTS:  Mission  Requirements 

OUTPUTS:  Feasibility  Studies,  Alternative  Approaches 

Cost/Schedule  Estimates,  Risk  Assessment 
CONTROLS:  SPO 

MECHANISMS:  Contractor 

Perform  Concept  Development  -  Box  All 2 

INPUTS:  Feasibility  Studies,  Alternative  Approaches,  Cost/Schedule  Estimates, 

Risk  Assessment 

OUTPUTS:  System  Concept  Strategies 

CONTROLS:  SPO 

MECHANISMS:  Contractor 

Generate  Preliminary  Planning  Document  -  Box  A113 

INPUTS:  Feasibility  Studies,  Alternative  Approaches,  Cost/Schedule  Estimates, 

Risk  Assessment 

OUTPUTS:  Draft  CRISD,  TEMP,  CRLCMP 

CONTROLS:  SPO 

MECHANISMS:  Contractor 

Select  Concept  -  Box  All 4 

INPUTS:  System  Concept  Strategies 

OUTPUTS:  System  Concept 

CONTROLS:  Draft  CRISD,  TEMP,  CRLCMP 

MECHANISMS:  SPO/Contractor 
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NODE:  TITLE:  NUMBER: 

Level  2  Conduct 

node  A1 1  Concept  Exploration 


B.2.1.5  Conduct  Demonstration/Validation  -  Node  A12 

The  purpose  of  the  demonstration/validation  phase  is  to  validate  the  selection  made  from  the 
alternatives  provided  in  the  previous  phase.  While  actual  software  requirements  may  not 
have  been  defined,  the  software  development  methodologies  may  be  defined  at  this  time. 

Conduct  Engineering  Studies  -  Box  A121 

INPUTS:  System  Concept 

OUTPUTS:  Feasibility  Studies,  FFBD,  Trade-Off  Studies 

CONTROLS:  AFR  800-14 

MECHANISMS:  Contractor 


Expedite  Support  Functions  -  Box  A122 

INPUTS:  Feasibility  Studies,  FFBD,  Trade-Off  Studies 

OUTPUTS:  CRISD,  CRLCMP,  TEMP,  Test  Plan 

CONTROLS:  AFR  800-14 

MECHANISMS:  SPO/CRWG,  SPO  Parent  Authority 

Develop  Prototype  (Optional)  -  Box  A1 23 

INPUTS:  System  Concept,  Feasibility  Studies,  FFBD,  Trade-Off  Studies 

OUTPUTS:  Prototype  Module 

CONTROLS:  AFR  800-14,  DOD-STD-2167A 

MECHANISMS:  Contractor 


Conduct  System  Requirements  Review  -  Box  A124 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS 


Prototype  Module,  Feasibility  Studies,  FFBD,  Trade-Off  Studies 

CRISD,  CRLCMP,  TEMP,  Test  Plan 

Validated  System  Requirements 

AFR  800-14,  MI1^STD-1521B 

SPO 
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N0DE:  Level  2  TITLE;  Conduct  NUMBER; 

node  A12  Demonstation/Validation 


B.2.1.6  Conduct  Full  Scale  Development  -  Node  A13 

During  the  full  scale  development  phase,  the  design  and  development  of  the  system  takes 
place.  This  phase  includes  the  entire  software  development  cycle.  Towards  the  end  of  this 
phase,  the  software  configuration  items  are  integrated  with  the  hardware,  prior  to  system  test¬ 
ing. 

Perform  System  Requirements  Analysis  -  Box  A131 

INPUTS:  Validated  System  Requirements  (B5),  Feedback/Comments  to 

Developer 

OUTPUTS:  Software  Requirements 

CONTROLS:  DODD  5000.31,  AFR  700-9,  MII^STD-490A,  DOD-STD-2167A, 

DOD-STD-1521B 
MECHANISMS:  Contractor 

Develop  Preliminary  Design  -  Box  A132 

INPUTS:  Validated  Specification,  Feedback/Comments  to  Developer 

OUTPUTS:  Developmental  Configuration 

CONTROLS:  DOD-STD-2167A,  DOD-STD-1521B 

MECHANISMS:  Contractor 


Develop  Detailed  Design  -  Box  A133 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


Developmental  Configuration,  Feedback/Comments  to  Developer 
CRLCMP  Updates,  Developmental  Configuration 
DOD-STD-2 1 67 A,  DOD-STD-1521B 
Contractor 


Code  &  Test  -  Box  A134 


INPUTS: 

OUTPUTS; 

CONTROLS: 

MECHANISMS: 


Developmental  Configuration,  Feedback/Comments  to  Developer, 

Feedback/Deficiencies 

CPCIs 

DOD-STD-2167A,  DOD-STD-1521B,  DODD  5000.31,  AFR  800-14 
Contractor 


Conduct  Audit  -  Box  A 135 


INPUTS; 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


CPCIs 

Authenticated  CPCIs,  Feedback/Deficiencies 

DOD-STD-2167A,DOD-STD-1521B,  DODD  5000.31,  AFR  800-14 
SPO 
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Conduct  Software  Specification  Review  (SSR)  -  Box  A136 


INPUTS:  Software  Requirements 

OUTPUTS:  Validated  Specification 

CONTROLS:  DOD-STD-2167A,  DOD-STD-1521B 

MECHANISMS:  Contractor 

Update  CRLCMP  -  Box  A137 

INPUTS:  CRLCMP  Updates 

OUTPUTS:  Updated  CRLCMP 

CONTROLS:  AFR  800-14 

MECHANISMS:  CRWG 


Provide  Software  Quality  Evaluation  -  Box  A138 

INPUTS:  Software  Requirements,  Developmental  Configuration,  CPCIs 

OUTPUTS:  Feedback/Comments  to  Developer 

CONTROLS:  (A1223)  Quality  Evaluation  Plan 

MECHANISMS:  SPO 

Request  CPINs  -  Box  A139 

INPUTS:  Developmental  Configuration 

OUTPUTS:  AF  Form  1244 

CONTROLS:  TO-OO-5-16 

MECHANISMS:  SPO/ALC 


Assign  CPINs  -  Box  A13_10 


INPUTS; 

OUTPUTS; 

CONTROLS: 

MECHANISMS: 


AF  Form  1244 
CPIN  (A143) 
TO-OO-5-16 
OC-ALC/MMEDU 
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B.2.1.7  Production/Deployment  -  Node  A14 


Production/Deployment  is  the  final  phase  of  the  acquisition  cycle.  During  this  phase,  weapon 
systems  are  produced  using  the  design  developed  during  FSD.  In  terms  of  software,  the  SPO 
is  still  responsible  for  the  initial  maintenance  of  the  software,  but  this  function  may  eventually 
be  performed  by  the  developing  contractor. 

Conduct  Operational  Test  &  Evaluation  -  Box  A 141 

INPUTS;  (A21)  Authenticated  CSCIs  (Imbedded  w/in  System) 

OUTPUTS;  Test  Results 

CONTROLS;  AFR  80-14 

MECHANISMS:  Using  Command,  SPM 

Provide  Operational  Certification  -  Node  A 142 

INPUTS:  Test  Results 

OUTPUTS;  Certification 

CONTROLS:  AFR  80-14 

MECHANISMS;  Using  Command 

Distribute  CSDls  -  Box  A 143 

INPUTS;  CPIN  Assignment  (A13_10),  Test  Results,  Certification 

OUTPUTS:  Distribution  Package,  CSDls  for  Distribution  (A134) 

CONTROLS:  AFR  80-14,  TO-OO-5-16 

MECHANISMS:  SPO 


Maintain  Fielded  Systems  -  Box  A144 


INPUTS: 


OUTPUTS: 

CONTROLS; 

MECHANISMS: 


Change  Requests  (A21),  Distribution  Package,  Authenticated  CSCIs 
(Imbedded  within  System) 

Current  System  Configuration 

AFR  80-14 

SPO 


Execute  PMRT  -  Box  A 145 


INPUTS; 

CONTROLS: 

MECHANISMS: 


Current  System  Configuration 
System  Turnover 
MIL-STD-800-18 

PMRT  Working  Group,  SPO,  Using  Command,  SPM 
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B.2.1.8  Conduct  Engineering  Studies  -  Node  Alll 

One  of  the  initial  technical  tasks  during  the  Concept  Exploration  is  the  technical  assessment 
of  the  mission  requirements.  This  analysis  is  developed  through  preliminary  engineering  stu¬ 
dies.  These  studies  include  feasibility  reports,  cost/schedule  estimates,  risk  estimates,  etc. 
These  studies  form  the  basis  of  development  of  the  preliminary  concepts.  While  software 
requirements  will  not  be  addressed  until  the  latter  part  of  the  Demonstration/Validation 
phase,  computer  resources  needed  to  support  the  system  are  initially  identified. 

Requirements  Allocation  -  Box  All  11 

PSOC,  SOC,  SON 
Initial  Requirements  Allocation 
SPO,  AFR  800-14 
Contractor 

Conduct  Operational  Concept  Analysis  -  Box  A1112 

Initial  Requirements  Allocation 
Concept  of  Operations,  Cost  &  Schedule  Estimates 
SPO,  AFR  800-14 
Contractor 

Conduct  Trade-Off  &  Optimization  Studies  -  Box  All  13 

Initial  Requirements  Allocation,  Concept  of  Operations 
Alternative  Computer  Resource  Approaches 
SPO,  AFR  800-14 
Contractor 

Conduct  Feasibility  Studies  -  Box  All  14 

Initial  Requirements  Allocation,  Concept  of  Operations 
Feasibility  Studies 
SPO,  AFR  800-14 
Contractor 

Perform  Risk  Analysis  -  Box  All  15 

Initial  Requirements  Allocation,  Concept  of  Operations 
Risk  Assessment 
SPO,  AFR  800-14 
Contractor 


B.2.1.9  Perform  Concept  Development  -  Node  A112 

Node  A112,  Perform  Concept  Development,  identifies  the  activities  associated  with  develop¬ 
ing  working  concepts  based  on  functional  analysis  as  well  as  trade-off  analysis.  The  concepts 
developed  during  this  activity  are  used  in  other  activities  such  as  trade-off  analysis.  The  ob¬ 
jective  of  this  process  is  to  provide  an  approach  which  may  take  advantage  of  more  than  one 
concept. 

Perform  Functional  Analysis  -  Box  A1121 

INPUTS:  Operational  Concept  Analysis  (All  1) 

OUTPUTS:  Preliminary  Functional  Requirements 

CONTROLS:  AFLCR  800-21 

MECHANISMS:  Contractor 

Conduct  System  Synthesis  -  Box  A1122 

INPUTS:  Operational  Concept  Analysis  (Alll),  Preliminary  Functional 

Requirements 

OUTPUTS:  Schematic  Block  Diagrams,  System  Alternatives 

CONTROLS:  AFLCR  800-21,  Technology  Selection  Factor 

MECHANISMS:  Contractor 

Formulate  Product  Concepts  -  Box  A1123 

INPUTS:  Schematic  Block  Diagrams,  System  Alternatives 

OUTPUTS:  System  Concept  Strategies 

CONTROLS;  AFLCR  800-21 

MECHANISMS:  Contractor 
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B. 2.1. 10  Generate  Preliminary  Planning  Documents  -  Node  A113 

Node  A113,  Generate  Preliminary  Planning  Documents,  identifies  activities  associated  with 
the  development  of  various  planning  documents.  These  documents  identify  the  requirements 
for  the  testing,  integration  and  management  of  ECS  software  throughout  the  system  life  cycle. 


Charter  CRWG  -  Box  A1131 


INPUTS: 
OUTPUTS: 
CONTROl  S: 
MECHANISMS: 


CRWG  Requirements 

CRWG 

AFR  800-14 

SPO,  DPML,  Using  Command 


Perform  Test  Planning  -  Box  A1132 

INPUTS:  System  Analysis  Information 

OUTPUTS:  Test  Objectives 

CONTROLS:  AFR  80-14,  DODD  5000.3 

MECHANISMS:  TPWG 


Draft  CRLCMP  -  Box  A1133 

INPUTS:  System  Analysis  Information 

OUTPUTS:  Draft  CRLCMP 

CONTROLS:  CRWG 

MECHANISMS:  SPO,  DPML,  Using  Command 

Draft  CRISP  -  Box  A1134 

INPUTS:  System  Analysis  Information 

OUTPUTS:  Draft  CRISP 

CONTROLS:  AFLCR  800-21,  AFR  800-14 

MECHANISMS:  CRWG 

Assess  Need  for  IV&V  -  Box  A1135 

INPUTS:  System  Analysis  Information 

OUTPUTS:  IV&V  Requirements 

CONTROLS:  AFLCR  800-21,  AFR  800-14 

MECHANISMS:  CRWG 

Develop  Draft  TEMP  -  Box  A1136 

INPUTS:  Test  Objectives,  Draft  CRLCMP,  IV&V  Requirements 

OUTPUTS:  Draft  TEMP 

CONTROLS:  AFR  800-14,  DODD  5000.3 

MECHANISMS:  TPWG 
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NODE:  TITLE:  NUMBER: 

l_evei  3  Generate  Preliminary 

node  All 3  Planning  Documents 


CRLCMP 

Si 

UXSi 

KQLSi 

IANTSMS: 


Box A1137 

Draft  CRLCMP,  IV&V  Requirements 
Draft  CRLCMP 
AFLCR  800-21,  AFR  800-14 
SPO,  DPML,  Using  Command 
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B.2.1.11  Select  Concept  -  Node  A114 


Using  the  concepts  and  strategies  developed  in  Node  A112,  an  approach  is  selected.  As 
pointed  out  in  the  DMSC  System  Engineering  Management  Guide,  this  selection  is  less  a 
selection  of  a  particular  approach,  but  “more  an  identification  of  feasible,  affordable  ranges 
of  cost  and  system  effectiveness.”  This  information  formulates  the  basis  of  the  Type  A  System 
Specification. 

Integrate  &  Develop  Concepts  -  Box  A1I41 
INPUTS:  System  Concept  Strategies 

OUTPUTS:  FFBD,  RAS  Interface  Studies,  Mission  Area  Analysis,  TSR 

CONTROLS:  AFLCP/AFSCP  800-34 

MECHANISMS:  Contractor 


Select  Approach  -  Box  A1142 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


FFBD,  RAS  Interface  Studies,  Mission  Area  Analysis,  TSR 
System  Concept 
AFLCP/AFSCP  800-34 
Contractor,  SPO,  DPML 
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B.2.1.12  Conduct  Engineering  Studies  -  Node  A121 

A  variety  of  engineering  studies  based  on  the  concepts  selected  in  the  previous  phase  take 
place  during  the  Demonstration/Validation  phase.  These  studies  include  feasibility  studies, 
risk  assessments  and  trade-off  studies.  The  products  generated  within  this  activity  support 
the  System  Requirements  Review  (SRR),  the  IRS  and  the  Softv^are  Development  Risk  Man¬ 
agement  Plan. 

Determine  Initial  Allocation  of  Software  Cl  Requirements  -  Box  A12I1 
INPUTS:  A-Spec 

OUTPUTS:  Change  to  Preliminary  Allocation  of  Software  Requirements 

CONTROLS:  AFR  800-14 

MECHANISMS:  Contractor 

Determine  Interface  Requirements  -  Box  A1212 
INPUTS:  A-Spec 

OUTPUTS:  Interface  Requirements  Specification 

CONTROLS:  AFR  800-14 

MECHANISMS;  Contractor 

Conduct  Tradeoff  &  Optimization  Studies  -  Box  A1213 

INPUTS:  A-Spec 

OUTPUTS:  Trade-off  Studies  (A124) 

CONTROLS:  AFR  800-14 

MECHANISMS:  Contractor 

Conduct  Feasibility  Studies  -  Box  AI214 

INPUTS.;  A-Spec 

OUTPUTS:  Feasibility  Studies  (A124) 

CONTROLS:  AFR  800-14 

MECHANISMS:  Contractor 

Perform  Risk  Analysis  -  Box  A1215 

INPUTS:  A-Spec 

OUTPUTS:  Software  Development,  Risk  Management  Plans  (A1225) 

CONTROLS:  AFR  800-14 

MECHANISMS:  Contractor 
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B.2.1.13  Expedite  Support  Functions  -  Node  A122 


A  number  of  support  related  activities  that  take  place  during  the  Demonstration/Validation 
phase  are  identified  in  Node  A122  as  “Expedite  Support  Functions”.  As  the  definition  of  the 
system  software  begins  to  take  shape,  test  plans  for  the  software  can  be  formulated. 

Along  with  the  initial  allocation  of  CSCIs,  a  CM  plan  defining  all  aspects  of  CM  will  be  devel¬ 
oped.  This  process  would  include  change  processing,  the  role  of  the  contractor  during  devel¬ 
opment,  management  of  the  development  library,  etc. 

Prior  to  FSD,  a  software  quality  evaluation  program  is  developed.  This  program  sets  the  cri¬ 
teria  by  which  the  software  could  be  evaluated  throughout  the  development.  The  items  eva¬ 
luated  include  software  engineering,  software  management,  and  software  configuration  man¬ 
agement.  To  prepare  for  support  of  the  system  throughout  its  life  cycle,  a  support  concept 
must  be  developed.  Generally,  previous  concepts  outlining  the  major  support  roles  can  be 
used.  It  is  in  the  CRLCMP  that  the  support  concept  is  enhanced. 

Detail  Software  Test  Plans  -  Box  A 1221 

INPUTS:  Draft  TEMP,  A-Spec 

OUTPUTS:  Test  Plan  (A134) 

CONTROL:  AFOTECP  800-2 

MECHANISMS:  Contractor 

Define  CM  Approach  for  Computer  Resources  -  Box  A1222 

INEUISi  A-Spec 

OUTPUTS:  CM  Plan  (A132) 

CONTROI  £:  MIL-STD-490 A  MIL^STD-481,  MIL-STD-483,  MIl^STD-480 

MECHANISMS:  Contractor 

Define  Software  Quality  Evaluation  Program  -  Box  A1223 
INPUTS:  A-Spec 

OUTPUTS:  Quality  Evaluation  Criteria  (A138) 

CONTROI  .S:  DOD-STD-2168 

MECHANISMS:  CRWG 

Select  Software  Support  Concept  -  Box  A1224 

INPUTS:  A-Spec,  Draft  CRLCMP  (A1 137) 

OUTPUTS:  Support  Concept  Recommendation 

CONTROLS:  AFR  800-14 
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B.2.1.14  Update  and  Approve  CRLCMP  -  Box  A1225 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


CRLCMP,  Support  Concept  Recommendation,  Software  Development 
Risk  Management  Plan 
CRLCMP 
AFR  800-14 

SPO,  SPO  Parent  Authority 
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B.2.1.15  Develop  Prototype  -  Node  A123 


Although  still  in  the  Demonstration/Validation  phase  ;t  is  possible  for  a  prototype  to  be  de¬ 
veloped.  While  this  would  normally  be  executed  during  FSD,  it  may  be  necessary  to  develop  a 
prototype  to  determine  the  feasibility  of  a  technology.  This  activity  to  a  large  extent  is  mir¬ 
rored  by  the  activity  depicted  in  Node  A13. 

Perform  Software  Requirements  Analysis  -  Box  A1231 

INPUTS:  System  Concept,  System  Analysis  Data  (Feasibility  Studies,  Trade-off 

Studies,  FFBD,  Feedback 
OUTPUTS:  SRS 

CONTROLS:  MIL-STD-1521B 

MECHANISMS:  Contractor 

Conduct  Software  Specification  Review  -  Box  A1232 
INPUTS:  SRS 

OUTPUTS:  Authenticated  SRS,  Feedback 

CONTROLS:  MIi^STD-1521B 

MECHANISMS:  SPO,  Contractor 

Develop  Preliminary  Design  -  Box  A1233 

INPUTS:  Authenticated  SRS,  Feedback 

OUTPUTS:  Preliminary  Design 

CONTROL:  DOD-STD-2167A 

MECHANISMS:  Contractor 

Conduct  Preliminary  Design  Review  -  Box  A1234 

INPUTS:  Preliminary  Design 

OUTPUTS:  Preliminary  Design,  Feedback 

CONTROLS:  MIL-STD-1521B 

MECHANISMS:  SPO,  Contractor 

Develop  Detailed  Design  -  Box  A 123 5 

INPUTS:  Preliminary  Design,  Feedback 

OUTPUTS:  Detailed  Design 

CONTROLS:  DOD-STD-2167A 

MECHANISMS:  Contractor 
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Conduct  Critical  Design  Review  -  Box  A1236 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS; 


Detailed  Design 
Validated  Design,  Feedback 
MID-STD-1521  B 
SPO,  Contractor 


Code  &  Unit  Test  CSUs  -  Box  A1237 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


Validated  Design 
CSUs 

MID-STD-1521B 

Contractor 


CSCs  Integration  and  Text  -  Box  A1238 


INPUTS; 

OUTPUTS: 

CONTRODS: 

MECHANISMS: 


CSUs,  Deficiencies,  Feedback 
CSC 

DOD-STD-2167A 

Contractor 


Conduct  Test  Readiness  Review  -  Box  A1239 


INPUTS: 

OUTPUTS; 

CONTROLS; 

MECHANISMS; 


CSC 

CSCs,  Feedback 
MID-STD-1521B 
SPO,  Contractor 


CSCIs  Testing  -  Box  A123_10 


INPUTS: 

OUTPUTS; 

CONTROLS: 

MECHANISMS: 


CSCs 

CSCIs,  Deficiencies 
AFR  80-14 
Contractor 


Conduct  Audits  -  Box  A123_ll 


INPUTS; 

OUTPUTS: 

CONTROLS; 

MECHANISMS; 


CSCIs 

Authenticated  CSCIs 
MIL^STD-1521B 
SPO,  Contractor 
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B.2.1.16  Conduct  System  Requirements  Review  -  Node  A124 

The  objective  of  the  SRR  is  to  determine  the  adequacy  of  the  requirements  identified  to  date. 
This  is  done  iiuough  the  review  of  documents  which  repicscnt  the  system  engineering  efiurts 
completed  at  this  time.  These  documents  include  the  FFBD,  the  RAS,  Mission  area  analysis, 
system  trade  studies,  system/cost  effectiveness,  life  cycle  cost  estimates,  system  interface  stu¬ 
dies,  preliminary  manufacturing  plans,  manpower  requirements.  These  documents  formu¬ 
late  the  basis  of  the  baseline. 

Appendix  A  of  MIL-STD-1521B  identifies  in  more  detail  the  entire  spectrum  of  products 
which  may  need  review.  While  these  products  represent  the  functional  analysis  of  the  system 
requirements,  other  products  identifying  the  risk,  risk  avoidance  and  trade-offs  provide  a 
clearer  representation  of  workable  concepts  or  strategies. 

Identify  Items  to  be  Reviewed  -  Box  A1241 

INPUTS:  SOW 

OUTPUTS:  SRR  Review  Items 

CONTROLS:  MII^STD-1521B 

MECHANISMS:  Contractor 

Conduct  System  Requirements  Review  -  Box  A1242 

INPUTS:  Preliminary  Allocation  of  Software  Requirements,  Trade  Studies/ 

Feasibility  Studies,  Risk  Analysis/LSA 
OUTPUTS:  Modifications/Changes/Comments,  Minutes 

CONTROLS:  MIL^STD-1521B 

MECHANISMS:  Contractor,  SPO,  DPML 

Conduct  Post  Review  Action! Items  -  Box  AI243 

INPUTS:  Modifications/Changes/Comments,  Minutes 

OUTPUTS:  Validated  System  Requirements 

CONTROLS:  MIU-STD-1521B 

MECHANISMS:  Contractor 
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B.2.1.17  Perform  System  Requirements  Analysis  -  Node  A131 

The  requirements  analysis  generated  here  identifies  the  initial  software  requirements.  This 
set  of  requirements  is  usually  allocated  to  the  CSCI  level.  Documents  such  as  the  pre¬ 
liminary  SRS,  the  IRS,  and  the  SOC  are  used  during  this  process. 

Analyze  System  Requirements  -  Box  A1311 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


Validated  System  Requirements 

SSS,  Preliminary  OCD,  Preliminary  SRS,  Preliminary  IRS 

DOD-STD-2167A 

Contractor 


Determine  Software  Requirements  -  Box  A1312 


INPUTS: 

OUTPUTS; 

CONTROLS: 

MECHANISMS: 


SSS,  Preliminary  OCD,  Preliminary  SRS,  Preliminary  IRS 

CSCI  Requirements 

DOD-STD-2167A 

Contractor 


Conduct  Software  Design  Review  (SDR)  -  Box  A1313 


INPUTS: 

OUTPUTS; 

CONTROLS: 

MECHANISMS: 


SSS,  Preliminary  OCD,  Preliminary  SRS,  Preliminary  IRS, 
CSCI  Requirements 

Software  Requirements,  Action  Items/Deficiencies 
DOD-STD-2167A,  MII^STD-1521B 
Contractor,  SPO 
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B.2.1.18  Develop  Preliminary  Design  -  Node  A132 

Using  the  validated  specification  from  the  Software  Specification  Review  (SSR),  a  prelimi¬ 
nary'  design  or  “developmental  configuration”  is  established.  The  preliminary  design  is  com¬ 
posed  of  several  products  which  comprise  a  “first  cut”  at  the  development  of  a  working  soft¬ 
ware  model.  These  products  include  data  flow  diagrams,  functional  flow  block  diagrams,  and 
trade-off  studies.  The  activity  within  this  node  is  the  PDR.  The  PDR  is  used  to  validate  the 
initial  design  prior  to  the  development  of  a  detailed  design. 


Analyze  Specification  Documents  -  Bux  A1321 


INPUTS; 

OUTPUTS: 

CONTROLS; 

MECHANISMS: 


SRS,  OCD 
Analyzed  SRS,  OCD 
Contractor  Practices 
Contractor 


Analyze  Interface  Requirements  -  Box  A1322 


INPUTS: 

OUTPUTS- 

CONTROLS; 

MECHANISMS: 


Analyzed  SRS,  OCD,  Interface  Requirements  Specification 
Authenticated  CSCI  Requirements 
Contractor  Practices 
Contractor 


Draft  Preliminary  Design  -  Box  A1323 


INPUTS; 

OUTPUTS; 

CONTROLS; 

MECHANISMS: 


Authenticated  CSCI  Requirements,  Action  Items/Deficiencies 

FFBD,  DFDs,  Trade-off  Studies,  Models,  TLCSC,  Preliminary  Data 

Dictionary 

DOD-STD-2167A 

Contractor 


Conduct  Preliminary  Design  Review  -  Box  A1324 


INPUTS: 

OUTPUTS: 

CONTROLS; 

MECHANISMS: 


FFBD,  DFDs,  Trade-off  Studies,  Models,  TLCSC,  Preliminary  Data 
Dictionary 

Developmental  Configuration,  Action  Items/Deficiencies 
DOD-STD-2167A,  MIL-STD-1521B 
Contractor,  SPD,  DPML 
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B.2.1.19  Develop  Detailed  Design  -  Node  A133 

Node  A133,  Develop  Detailed  Design,  identifies  the  activities  associated  with  developing  a 
preliminary  design  into  a  detailed  design.  This  process  involves  the  analysis  of  the  preliminary 
design  package,  and  the  development  of  the  detailed  design  information.  This  process  gener¬ 
ally  involves  the  breakdown  or  decomposition  of  CSCs  into  Lower  Level  CSC  (LLCSCs).  It 
can  also  involve  the  identification  of  internal  and  external  interfaces.  This  detailed  informa¬ 
tion,  in  the  form  of  a  detailed  design  package,  is  presented  for  review  at  the  Critical  Design 
Review  (CDR). 

Analyze  Preliminary  Design  Package  -  Box  A1331 

INPUTS:  Developmental  Configuration  (A1324) 

OUTPUTS:  Analysis 

CONTROLS:  DOD-STD-2167A 

MECHANISMS:  Contractor 

Detail  Preliminary  Design  Functions  -  Box  A1332 

INPUTS:  Analysis 

OUTPUTS:  Interface  Requirements 

CONTROLS:  DOD-STD-2167A 

MECHANISMS:  Contractor 

Develop  Detailed  Design  Package  -  Box  A1333 

INPUTS:  Interface  Requirements,  Developmental  Configuration,  Problems/ 

Action  Items/Deficiencies 

OUTPUTS:  LLCSC/Units,  Internal/Extemal  Interfaces,  Data 

CONTROLS:  DOD-STD-2167A 

MECHANISMS:  Contractor 

Conduct  Critical  Design  Review  -  Box  A1334 

INPUTS:  LLCSC/Units,  Internal/External  Interfaces,  Data 

OUTPUTS:  Changes  to  CRLCMP  (A137),  Developmental  Configuration  (A134) 

CONTROLS:  DOD-STD-2167A  MII^STD-1521B 

MECHANISMS:  SPO,  DPML,  Contractor 
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SPO,  DP  TIL, 
Contractor 


B.2.1.20  Code  &  Test  -  Node  A134 


Subsequent  to  CDR,  preliminary  coding  and  testing  efforts  are  initiated.  These  activities  are 
identified  in  Node  A134,  Code  &  Test  The  process  is  cyclical  in  that  code  is  generated,  tested, 
then  integrated  at  the  CSU,  CSC,  and  CSCI  level  respectively.  It  should  be  noted  that  at  each 
cycle.  Software  Deficiency  Reports  (SDRs)  loop  back  to  the  developer  in  the  event  of  an  un¬ 
successful  test.  Upon  successful  completion  of  the  CSCI  test,  the  approved  items  are  now 
available  for  integration  into  the  system,  prior  to  system  test. 


Generate  Code  for  Each  CSU  -  Box  A1341 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


(A133)  Developmental  Configuration,  Software  Deficiency  Reports 
CSU  Code 

DOD-STD-2167A,  MIL^STD-1521B,  DODD  5000.31,  AFR  800-14 
Contractor 


Generate  Preliminary  Documentation  -  Box  A1342 

INPUTS:  CSU  Code 

OUTPUTS:  CSU  Document 

CONTROLS:  DOD-STD-2167A,  MII^-STD-1521B,  DODD  5000.31,  AFR  800-14 

MECHANISMS:  Contractor 


ll'st  CSU  -  Box  A1343 

INPUTS:  CSU  Code,  Test  Plan 

OUTPUTS:  Tested  CSU,  SDRs,  CSU  Document 

CONTROLS:  DOD- STD-2167A,  MID-STD- 152  IB, 

TEMP 

MECHANISMS:  Contractor 

Integrate  CSUs  Into  CSCs  -  Box  AI344 

INPUTS:  CSU  Tested,  CSU  Document,  SDRs 

OUTPUTS:  Consolidated  CSCs 

CONTROLS:  DOD-STD-2167A,  MIL-STD-1521B 

MECHANISMS:  Contractor 


Test  CSCs  -  Box  A 1345 


INPUTS: 

OUTPUTS 

CONTROLS: 

MECHANISMS: 


Consolidated  CSCs,  Test  Plan 
Approved  CSCs,  SDRs 
DOD-STD-2167A  MIl^STD-1521B, 
TEMP 
Contractor 
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Integrate  CSCs  Into  CSCIs  -  Box  A1346 


INPUTS:  Approved  CSCs,  SDRs,  Deficiencies 

OUTPUTS  CSCI  Data 

CONTROLS:  DOD-STD-2167A,  MII^STD-1521B 

MECHANISMS:  Contractor 

Conduct  Test  Readiness  Review  -  Box  AI347 

INPUTS:  CSCI  Data,  Test  Plan 

OUTPUTS  Preliminary  CSCIs,  Deficiencies 

CONTROLS:  MIL-STD-1521B 

MECHANISMS:  SPO,  Contractor 

Test  CSCIs  -  Box  A1348 


INPUTS:  Preliminary  CSCIs 

OUTPUTS  Tested  CSCIs,  SDRs 

CONTROLS:  TEMP 

MECHANISMS:  Contractor 


Integrate  CSCIs  Into  System  and  Test  -  Box  A1349 


INPUTS: 

OUTPUTS 

CONTROLS: 

MECHANISMS: 


Tested  CSCIs 

Integration  Test  Approved  CSCIs  (A134) 
DOD-STD-2167A,  MID-STD-1521B 
Contractor 
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B.2.1.21  Conduct  Audits  -  Node  A135 

Node  A135,  Conduct  Audits,  identifies  the  audits  and  reviews  available  to  the  Air  Force. 
These  audits  and  reviews  provide  an  opportunity  to  determine  compliance  with  functional 
and  contractual  requirements.  Each  one  is  described  below. 

Appendix  G  of  MIL-STD-1521B  describes  the  objective  and  requirements  for  conducting  a 
Functional  Configuration  Audit  (FCA).  While  this  appendix  applies  to  both  hardware  and 
software,  only  the  software  component  is  discussed  here. 

There  are  several  components  to  the  FCA  for  CSCIs.  They  are  as  follows: 

•  A  briefing  for  each  CSCI,  those  requirements  which  were  not  met  by  that 
CSCI,  and  proposed  solutions, 

•  Test  plan  documentation  audited  against  official  test  data,  and 

•  An  audit  of  the  STR  to  verify  the  accuracy. 

As  part  of  the  update  process.  Engineering  Change  Proposal  (ECPs)  and  updates  to  previous¬ 
ly  delivered  documentation  will  be  reviewed  for  consistency  with  the  CSCI  and  the  specifica¬ 
tion  will  be  documented. 

The  objective  of  the  Physical  Configuration  Audit  (PCA),  is  to  verify  the  configuration  item 
against  the  design  documentation.  Specifically,  this  review  will  include  the  Software  Product 
Specification  (SPS),  the  Version  Description  Document  (VDD),  and  the  Programmer,  User, 
System  Operator  and  Firmware  Support  manuals.  This  review  will  focus  on  the  completeness 
and  format  aspects  of  these  items.  ’  e  manuals  will  not  be  formally  accepted  until  system 
testing  has  taken  place,  thereby  continuing  procedural  validity. 

Formal  Qualification  Review  (FQR)  should  coincide  with  FCA  however  if  this  is  not  possi¬ 
ble,  FQR  can  be  conducted  independently.  As  with  the  previous  two  audits,  the  objective  of 
the  FQR  is  to  establish  compliance  of  the  system  configuration  items  with  appropriate  specifi¬ 
cations.  This  is  generally  accomplished  through  verification  of  test  data. 

Conduct  FCA  -  Box  A1351 

INPUTS:  Completed  and  Tested  CSCIs  (A134) 

OUTPUTS:  FCA  Minutes,  Deficiencies 

CONTROLS:  MIL-STD-1521B 

MECHANISMS:  SPO,  Contractor,  DPML 

Conduct  PCA  -  Box  A1352 

INPUTS:  FCA  Minutes,  Completed  and  Tested  CSCIs  (A134) 

OUTPUTS:  Deficiencies 

CONTROLS:  MII^STD-1521B 

MECHANISMS:  SPO,  Contractor,  DPML 
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Conduct  Audits 


Conduct  FQA  -  Box  A1353 


INE.UIS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


Completed  and  Tested  CSCIs  (A134) 
Deficiencies,  Developmental  Certification 
MII^STD-1521B 
SPO,  Contractor,  DPML 
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B.2.1.22  Conduct  Software  Specification  Review  -  Node  A136 

Node  A136,  Conduct  Software  Specification  Review,  identifies  the  activities  associated  with 
the  review  of  the  SRS  and  the  IRS.  Appendix  C  MII^STD-1521B  details  the  items  within 
both  specificatioas  to  be  reviewed.  These  factors  include,  but  are  not  limited  to  functional 
and  physical  characteristics  of  each  CSCI,  interface  characteristics,  as  well  as  other  logistic 
characteristics  (usability,  maintainability,  portability,  etc.). 

Plan  for  Software  Specification  Review  (SSR)  -  Box  A1361 


Conduct  Softwatt  Specification  Review  -  Box  A1 363 


INPUTS: 


OCD,  IRS,  SRS 
Review  Minutes 
MII^STD-1521B 
SPO,  Contractor 


Correct  Deficiencies  in  Requirements  Allocation  -  Box  A1364 


INPUTS: 


Review  Minutes,  Requirements  Documents  (SRS,  IRS,  OCD) 
Validated  Requirements  Specification  (A132) 
MIL^STD-1521B 
Contractor 
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N^DE'  Level  3  TITLE.  Conduct  Software 

node  A 136  Specification  Review 


B.2.2  Deployment  and  Management  IDEFs 

The  SPD  deployment  and  management  node  tree  (FIGURE  B-3)  includes  life  cycle  of  the 
software  after  PMRT.  It  consists  of  two  major  activities;  system  deployment  and  system  sup¬ 
port.  System  deployment  is  the  primary  activity  outlined  for  the  Using  Command. 
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Deploy  &  Manage  Weapon 
System  Software  (PDSS) 
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FIGURE  B-3.  SPD  DEPLOY  &  MANAGE  NODE  TREE 


B.2.2.1  Deploy  &  Manage  Weapon  System  Software  -  Node  A2 

Node  A2  encompasses  the  life  cycle  of  the  software  subsequent  to  PMRT.  It  consists  of  two 
major  activities;  system  deployment  and  system  support.  The  system  deployment  is  the  prima¬ 
ry  activity  outlined  for  the  using  command  (Node  A21).  Maintenance  of  the  system  and  the 
ECS  software  is  depicted  in  Node  A22. 


Deploy  System  -  Box  A21 


INPUTS; 

OUTPUTS; 

CONTROLS; 

MECHANISMS: 


Initial  Receipt  of  System,  Updates  to  TOs,  Change  Pages, 
Updates  to  Software  CSDIs 

Change  Requests/Feedback,  Certification  to  Changes 
Mission  Requirements 
Using  Commands 


Manage  ECS  Software  -  Box  A22 


INPUTS: 

OUTPUTS; 

CONTROLS: 

MECHANISMS: 


Change  Requests/Feedback,  Certification  to  Changes 
Updates  to  TOs,  Change  Pages,  Updates  to  Software  CSDIs 
CRLCMP,  O/S  CMP,  DOD-STD-2167A,  MII^STD-490A 
CCB,  SCCSB,  AFOTEC,  Support  Contractor 
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B. 2.2.2  Deploy  Weapon  System  Software  -  Node  A21 

This  node,  A21,  depicts  the  primary  Using  Command  activities.  During  PMRT,  the  Using 
Command  is  responsible  for  certification  efforts.  The  training  activity  identifies  preparation 
not  only  for  users  of  the  system  but  the  maintainers  as  well.  The  primary  activity  within  this 
node  is  the  deployment  of  the  system.  During  this  activity  the  system  meets  the  requirements 
levied  upon  it  through  the  mission  requirements.  When  deviations  to  the  mission  or  deficien¬ 
cies  within  the  system  itself  occur,  there  is  a  feedback  loop.  This  feedback  will  be  primarily  in 
the  form  of  a  Material  Improvement  Program  (MIP),  a  Materiel  Deficiency  Report  (MDR)  or 
a  Software  Problem  Report  (SPR).  These  requests  form  the  basis  of  the  final  series  of  nodes 
which  identify  the  software  maintenance  operation. 

Conduct  Acceptance  Tests  -  Box  A211 

INPUTS:  System 

OUTPUTS:  Accepted  System 

CONTROLS:  Applicable  TOs 

MECHANISMS:  Using  Command 

Execute  System  Turnover  -  Box  A212 

INPUTS:  Accepted  System 

OUTPUTS:  Approved  Software  &  SPD 

CONTROLS:  Applicable  TOs 

MECHANISMS:  Using  Command 

Initiate  Training  -  Box  A213 

INPUTS:  Accepted  System 

OUTPUTS:  Trained  Personnel 

CONTROLS:  Applicable  TOs 

MECHANISMS:  Using  Command 

Deploy  System  -  Box  A214 

INPUTS:  Approved  Software  &  SPD 

OUTPUTS:  Deficiencies 

CONTROLS:  Mission 

MECHANISMS:  Trained  Personnel 

Provide  Feedback  -  Box  A215 

INPUTS:  Deficiencies 

OUTPUTS:  MIP/MDR/SDR 

CONTROLS:  Changing  Mission  Requirements 

MECHANISMS:  Using  Command 
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B.2.2.3  Manage  Weapon  System  Software  -  Node  A22 

Node  A22  depicts  the  management  of  software  upon  completion  of  PMRT.  The  CCB  and  the 
SCCSB  maintain  the  integrity  of  a  weapon  system’s  functional  configuration,  trace  changes, 
and  determine  the  effect  of  those  changes  on  functionality.  The  majority  of  configuration 
management  activity  involves  the  archiving  of  Post-PMRT  SPD  including  change  requests, 
and  updates  to  information  flows  and  code. 

Execute  PMRT  -  Box  A221 


INPUTS:  Contract  Deliverables 

OUTPUTS:  Initial  Configuration 

CONTROLS:  AFR  800-4,  PMRT  Plan 

MECHANISMS:  SPO,  SPM,  Using  Command,  PMRT  Working  Group 


Initiate  Configuration  Management  Support  -  Box  A222 


INPUTS: 

OUTPUTS: 

CONTROLS: 


MECHANISMS: 


Changes  to  System  Configuration,  Initial  Configuration 
Cl  Status 

AFR  800-14,  AFLCR  800-21,  AFR  65-3,  MII^STD-480, 
MID-STD-481,  MIL^STD-483,  MIU-STD-490,  O/S  CMP  or 
CRLCMP 
CCB,  SCCSB 


Provide  Software  Archival  Support  -  Box  A223 

INPUTS:  Cl  Status,  Initial  Configuration,  Contract  Deliverables 

OUTPUTS:  Archived  Products 

CONTROLS:  TO-OO-5-16 

MECHANISMS:  Software  Control  Center 


Initiate  Software  Support  Cycle  -  Box  A224 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


Archived  Products,  Change  Requests  (A21) 
CDSI,  Changes  to  System  Configuration 
O/S  CMP  (CRLCMP) 

SPM,  Contractor 
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B. 2.2.4  Execute  PMRT  -  Node  A221 


PMRT  take«  place  upon  completion  of  the  production  stage.  The  PMRT  Working  Group, 
made  up  primarily  of  SPO,  Using  Command,  SPM  and  Contractor  members,  works  to  ensure 
that  the  software  and  system  meet  their  functional  requirements  and  that  adequate  support 
data  and  products  are  delivered.  Upon  completion  of  PMRT,  responsibility  for  the  software 
and  its  support  is  transferred  from  Developing  Command  to  the  Supporting  Command. 

Plan  for  PMRT  Meeting  -  Box  A2211 

INPUTS:  System  Turnover  Requirements 

OUTPUTS:  PMRT  Requirements 

CONTROLS:  AFR  800-4,  AFR  800-19 

MECHANISMS:  PMRT  Working  Group 

Conduct  PMRT  -  Box  A2212 


INPUTS: 
OUTPUTS: 
CONTROI S: 
MECHANISMS: 


PMRT  Requirements,  Configuration  Status  Information 
Initial  Configuration 
AFR  800-4,  AFR  800-19 
SPO,  SPM,  Using  Command 
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B.2.2.5  Initiate  Configuration  Management  -  Node  A222 

Configuration  Management  is  the  process  by  which  the  CCB  and  the  SCCSB  maintain  the 
desired  functionality  of  software.  The  process  involves  the  development  of  the  baselines  that 
make  up  configurations.  The  configuration  regulates  updates  to  software  and  associated 
products  as  a  result  of  user  change  requests,  and  system  audits  to  ensure  that  it  is  meeting 
CSCI  requirements  delineated  out  in  its  baseline  documents. 

Generate  Configuration  Identification  -  Box  A2221 

INPUTS:  Software  Development  Library/File 

OUTPUTS:  CM  Data,  Relationship 

CONTROLS:  O/S  CMP  (CRLCMP) 

MECHANISMS:  CCB 

Provide  CM  Control  -  Box  A2222 

INPUTS:  CM  Data,  Relationship,  Change  Request  (A21),  Trouble  Report  (A21) 

OUTPUTS:  Go-ahead  Decision  (A21),  Change  Action 

CONTROLS:  O/S  CMP  (CRLCMP) 

MECHANISMS:  CCB/Computer  Sub-Board 

Provide  Configuration  Status  Accounting  -  Box  A2223 

INPUTS:  Change  Action  Notice,  CM  Updates  (2232),  Change  Monitoring 

(A223) 

CM  Data,  Relationship 
OUTPUTS:  Current  Status 

CONTROI S:  O/S  CMP  (CRLCMP) 

MECHANISMS:  CCB 

Support  Configuration  Audits  -  Box  A2224 

INPUTS:  CM  Data,  Relationship,  Current  Status 

OUTPUTS:  Deviations/Discrepancies/Waivers 

CONTROLS:  O/S  CMP  (CRLCMP),  MIL-STD-1521B 

MECHANISMS:  SPO,  CCB,  Contractor 
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B.2.2.6  Institute  Software  Support  Cycle  -  Node  A223 

Node  A223,  Institute  Software  Support  Cycle,  identifies  the  activities  associated  with  supply¬ 
ing  the  weapon  system  with  software  support.  This  process  is  representative  of  the  “block 
change  cycle.”  The  block  change  cycle  is  the  process  whereby  a  group  or  “block”  of  changes 
are  planned  for  deployment  at  the  same  time. 

The  first  activity  initiates  the  change  process.  The  change  is  usually  in  the  form  of  an  improve¬ 
ment  to  the  system  or  a  record  of  a  deficiency.  A  system  impact  analysis  and  a  mission  impact 
analysis  are  required  prior  to  determining  whether  the  change  can  be  made. 

The  software  development  cycle  mirrors  the  development  cycle  used  during  the  FSD  phase. 
Upon  completion  of  test  and  certification,  the  TO  or  Time  Compliant  Technical  Order 
(TCTO)  must  be  developed.  Once  that  is  completed,  the  Software  Control  Center  adminis¬ 
ters  the  distribution  of  the  kit. 

Initiate  Change  Processing  -  Box  A2231 

INPUTS;  Change  Request  (A21) 

OUTPUTS:  Change  Status  (A21),  Change  Analysis  &  Change  Request 

CONTROLS:  O/S  CMP  (CRLCMP) 

MECHANISMS:  CCB 

Conduct  Software  Development  -  Box  A2232 

INPUTS:  Change  Analysis  &  Change  Request,  Archival  Products 

OUTPUTS:  Configuration  Management  Updates  (A22232),  CPIN  & 

Documentation  Updates  (A22332),  Updated  CSCIs 
CONTROLS:  O/S  CMP  (CRLCMP),  DOD-STD-2167A 

MECHANISMS:  MA_,  Support  Contractor 

Provide  Certification  &  Distribution  -  Box  A2233 

INPUTS:  Updated  CSCIs 

OUTPUTS:  CSDIs  (A21) 

CONTROLS:  O/S  CMP  (CRLCMP) 

MECHANISMS:  MA_,  SCC,  Using  Command 
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PROJECT:  CALS/SPD  ^  Q 

NOTES  • 

NODE:  A22 
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B.2.2.7  Initiate  Change  Processing  -  Node  A2231 


Node  A2231  describes  the  first  major  activity  in  the  software  support  cycle.  It  includes  the 
screening  of  the  request,  development  of  a  determination  of  impact,  and  a  decision  to  either 
implement  or  defer  the  change.  The  technical  analysis  includes  an  assessment  of  those  CPINs 
which  have  been  impacted. 

Initiate  Change  Request  Screening  -  Box  A223I1 
INPUTS:  Change  Request  (A21) 

OUTPUTS:  Rejection  Notice  (to  Initiator)  (A21),  Screened  Requests 

CONTROLS:  AFR  800-14,  Screening  Parameters 

MECHANISMS:  SCCSB 

Perform  System  Impact  Analysis  -  Box  A22312 

INPUTS:  Screened  Requests 

OUTPUTS:  Potential  Trade  Offs  to  Relevant  Systems 

CONTROLS:  System  Specification,  AFR  800-14 

MECHANISMS:  SCCSB 

Perform  Mission  Impact  Analysis  -  Box  A22313 

INPUTS:  Mission  Requirements 

OUTPUTS:  Potential  Tradeoffs  to  Relevant  Systems 

CONTROLS:  AFR  800-14,  Screened  Requests 

MECHANISMS:  SCCSB 

Perform  Technical  Analysis  -  Box  A22314 

INPUTS:  Potential  Tradeoffs  to  Relevant  Systems 

OUTPUTS:  Suggested  Changes/Technique 

CONTROLS:  AFR  800-14 

MECHANISMS:  SCCSB 

Assign  Change  Implementation  &  Track  -  Box  A223J5 

INPUTS:  Potential  Trade  Offs  to  Relevant  Systems,  Suggested  Changes/ 

Technique 

OUTPUTS:  Change  “Go-Ahead”  Notice  (A223),  Impact  Analysis  Reports  (A223) 

CONTROL:  AFR  800-14 

MECHANISMS:  SCCSB 
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B.2.2.8  Conduct  Software  Development  -  Node  A2232 

Node  A2232  details  the  activities  during  the  software  development  cycle.  This  process  was 
described  earlier  in  Node  A123. 


Perform  Requirements  Analysis  -  Box  A22321 


INPUTS; 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


Change  Request,  Impact  Analysis  Reports,  Change  Implementation 
Status,  Go  Ahead  Notice  (A2231) 

SRS 

SPM,  DOD-STD-2167A,  DOD-STD-2168,  Initial  Design  Parameters 
Contractor 


Generate  Preliminary  Design  -  Box  A22322 

INPUTS:  SRS 

OUTPUTS:  Preliminary  Design 

CONTROl -S:  DOD-STD-2!6T\  DOD-STD-2168 

MECHANISMS:  Contractor 


Generate  Detailed  Design  -  Box  A22323 

INPUTS:  Preliminary  Design 

OUTPUTS:  Detailed  Design 

CONTROLS:  DOD-STD-2167A,  DOD-STD-2168 

MECHANISMS:  Contractor 

Code  &  Unit  Test  -  Box  A22324 

INPUTS:  Detailed  Design 

OUTPUTS:  CSUs 

CONTROLS:  DOD-STD-2167A,  DOD-STD-2168 

MECHANISMS:  Contractor 

Integrate  &  Test  CSCs  -  Box  A22325 

INPUTS:  CSUs 

OUTPUTS:  CSCs 

CONTROLS:  DOD-STD-2167A,  DOD-STD-2168,  Test  Plan  Parameters 

MECHANISMS:  Contractor 

Test  CSC I  -  Box  A22326 


INPUTS: 

OUTPUTS: 

CONTROLS: 

MECHANISMS: 


CSCs 

Tested  CSCIs  (A2233) 

DOD-STD-2167A  DOD-STD-2168,  Test  Program  Sets,  Test  Plan 

Parameters 

Contractor 
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B.2.2.9  Provide  Certification  and  Distribution  -  Node  A2233 

Node  A2233  identifies  the  final  steps  in  the  block  change  cycle.  These  activities  include  the 
integration  and  test  of  the  software,  updating  manuals,  generating  the  necessary  technical  or¬ 
ders,  and  coordinating  the  distribution  through  the  SCC. 

Conduct  System  Integration  and  Test  -  Box  A22331 

INPUTS:  Tested  CSCIs  (A2232) 

OUTPUTS:  Validated  CSCIs 

CONTROLS:  CRLCMP,  O/S  CMP 

MECHANISMS:  MAS/SPM/SCC 

Update  Documentation  &  CPINs-  Box  A22332 

INPUTS:  Tested  CSCIs,  CPIN  &  Documentation  Updates  (A2232) 

C  JTPUTS:  Change  Pages,  etc. 

CONTROLS:  CRLCMP,  O/S  CMP 

MECHANISMS:  MAS/SPM/SCC 

Reproduction  &  Publishing  -  Box  A22333 


INPUTS:  Change  Pages,  etc. 

OUTPUTS:  Documentation  Updates,  Load  Instructions 

CONTROLS:  CRLCMP,  O/S  CMP 

MECHANISMS:  MAS/SPM/SCC 

Provide  Certification  -  Box  A22334 

INPUTS:  Validated  CSCIs 

QI 1 1PUTS:  Certification  Status 

CPNTROI S\  CRLCMP,  O/S  CMP,  Certification  Requirements 

MECHANISMS:  Using  Command 

Formulate  CSDIs  -  Box  A22335 

INPUTS:  Certification  Status,  Validated  CSCIs,  Documentation  Updates.  Load 

Instructions 

OU  ITU  I  S:  Distribution  Packages  (Change  Pages,  Software  Updates,  Institutes  TO 

Changes)  (A21) 

CONTROLS:  CRLCMP.  O/S  CMP 

MECHANISMS:  MAS/SPM/SCC 
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